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

[Zou, Nanhai]

Thanks,
This is the patch that deals with the format issue and removed the
return check of elf_dump_thread_status.

I think it's hard to drop the tasklist_lock  while we allocate the
memory unless we totally reorganize the elf_core_dump related functions
and data structures.

Zou Nan hai
-----Original Message-----
From: Andrew Morton [mailto:akpm@xxxxxxxx] 
Sent: Thursday, August 05, 2004 6:47 AM
To: Zou, Nanhai
Cc: linux-kernel@xxxxxxxxxxxxxxx; davidm@xxxxxxxxxxxxxxxxx; Luck, Tony
Subject: Re: [Patch 2.6.7]might-sleep-in-atomic while dumping elf

"Zou, Nanhai" <nanhai.zou@xxxxxxxxx> 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);

Attachment: might_sleep_dump_elf.patch
Description: might_sleep_dump_elf.patch