Re: [PATCH 05/37] kdb: core for kgdb back end
Andi Kleen <[email protected]> Thu, 24 Dec 2009 02:28:06 +0100
| Newsgroups | gmane.linux.kernel.cross-arch,gmane.linux.kernel,gmane.linux.kernel.debugging.kgdb.bugs,gmane.linux.kernel.debugging |
|---|---|
| Message-ID | <[email protected]> |
Jason Wessel <[email protected]> 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 -- [email protected] -- Speaking for myself only.