Re: [Patch 2.6.7]might-sleep-in-atomic while dumping elf

[Andrew Morton <akpm@osdl.org>]

"Zou, Nanhai" <nanhai.zou@intel.com> wrote:
>
> Here is a patch to fix a problem of might-sleep-in-atomic which
> David Mosberger mentioned at
> http://www.gelato.unsw.edu.au/linux-ia64/0407/10526.html
> 
> On IA64 platform, a might-sleep-in-atomic warning raise while dumping a
> multi-thread process.
> That is because elf_cord_dump hold the tasklist_lock before kernel doing
> a access_process_vm in elf_core_copy_task_regs, 
> 
> This patch detached elf_core_copy_task_regs function from inside
> tasklist_lock to remove the warning.

hm, OK, no worse than what we had there before :(

That GFP_ATOMIC allocation of one 824-byte-on-x86 structure for each
thread looks really, really nasty.  It could easily chew up 100% of the page
reserves and fail.  I wonder if it is safe to drop the tasklist_lock while we 
allocate the memory?

You're still testing for a zero return from elf_dump_thread_status().  I
think that with your changes, that is no longer possible, is it?

Please edit in 80-col xterms.  You'll find that a layout such as the below
becomes more agreeable.


+		list_for_each(t, &thread_list) {
+			struct elf_thread_status *tmp;
+			int sz;
+
+			tmp = list_entry(t, struct elf_thread_status, list);
+			sz = elf_dump_thread_status(signr, tmp);