lkml.org 
[lkml]   [2009]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 05/37] kdb: core for kgdb back end
From
Date
Jason Wessel <jason.wessel@windriver.com> writes:

I remember going with kaos through all the code
outside kdb/ in his own patch and for nearly all hooks
outside we found some way to eliminate them.

I think a lot of this is here too.

>
> +#ifdef CONFIG_KGDB_KDB
> +/* Like meminfo_proc_show() but without the locks and using kdb_printf() */
> +void kdb_meminfo_proc_show(void)

Are there even any locks in meminfo_proc_show()? I don't see any on a quick look.
Ah or is that only for swap_info? That could be a flag or perhaps that
access can be even made lockless (it looks like it could)

I guess a better way would be to have a kdb specific seq file implementation
and then just use the normal function, instead of copying everything.

> void get_vmalloc_info(struct vmalloc_info *vmi)
> {
> struct vm_struct *vma;
> unsigned long free_area_size;
> unsigned long prev_end;
> +#ifdef CONFIG_KGDB_KDB
> + int get_lock = !KDB_IS_RUNNING();
> +#else
> +#define get_lock 1
> +#endif
> +

A standard way to do such would be a __get_vmalloc_info with the
lock in the caller

Didn't read everything in this gigantic patch.

-Andi

--
ak@linux.intel.com -- Speaking for myself only.


\
 
 \ /
  Last update: 2009-12-24 02:31    [W:0.299 / U:0.464 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site