Messages in this thread | | | Subject | Re: [PATCH 05/37] kdb: core for kgdb back end | From | Andi Kleen <> | Date | Thu, 24 Dec 2009 02:28:06 +0100 |
| |
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.
| |