Messages in this thread Patch in this message | | | Date | Mon, 4 Feb 2002 20:51:40 -0600 (CST) | From | Clifford Kite <> | Subject | Kernel zombie threads after module removal. |
| |
Hello,
I sent the email below and attached patch, based on Kasper Dupont's patch for a 2.4.5 kernel, to Johannes Erdfelt <johannes@erdfelt.com> on Monday, October 15, 2001 but received no reply. The problem still exists in the 2.4.12 kernel, and, as far as I can tell by looking through the kernel patches through 2.4.17, the problem still hasn't been fixed.
Perhaps I was mistaken in sending the patch to him, so I'm sending it to the linux-kernel list this time. I'd really like to see this patch, or any patch that fixes the problem, get into the kernel source.
--- Best regards, Clifford Kite
Problem description ------------------------------------------------------------------------ This problem occurs in the kernels 2.4.5-ac9 and 2.4.12, with basic USB support compiled into both the kernels. After removing the usb-storage.o and the SCSI sd_mod.o modules two zombie kernel treads remain:
root 2985 0.0 0.0 0 0 ? Z 12:07 0:00 [usb-storage-0 <defunct>] root 2986 0.0 0.0 0 0 ? Z 12:07 0:00 [scsi_eh_0 <defunct>]
These zombies *accumulate*, a new pair appears for each time the modules are removed. The modules are inserted and removed manually with these commands in scripts:
/sbin/modprobe -a usb-uhci usb-storage sd_mod /sbin/modprobe -ar sd_mod usb-storage usb-uhci
The problem was fixed in 2.4.5-ac9 after applying a simple patch that Kasper Dupont sent in answer to my posts on colds for help. I was surprised to find that this is still a problem with the 2.4.12 kernel so this time I'm making an effort to get a fix incorporated into the kernel source.
Although I'm not a C programmer I can read C a bit, and it seemed that modifying the hub.c code for 2.4.12 in the same way as the previous patch did for 2.4.5-ac9 might fix the problem in it too. It did fix the problem, but it would be nice if the kernel sources were modified to fix it by the developer, either as done by Kasper's patch, or with other code that fixes the problem in a more appropriate way.
The 2.4.12 patch is included as an attachment in this email and includes comments by Kasper from the original patch for 2.4.5-ac9. I'll be glad to answer any questions you may have and to cooperate by applying any other patch to hub.c and testing it here. I posted a comment on colds after applying the fix describing my observations in more detail and can send it, if you think it might help.
--- --- hub.c-original Tue Oct 9 17:15:02 2001 +++ hub.c Sun Oct 14 21:09:18 2001 @@ -5,7 +5,9 @@ * (C) Copyright 1999 Johannes Erdfelt * (C) Copyright 1999 Gregory P. Smith * (C) Copyright 2001 Brad Hards (bhards@bigpond.net.au) - * + */ +/* Workaround to avoid zombies. (Untested) + * (C) 2001 Kasper Dupont <kasperd@daimi.au.dk> */ #include <linux/config.h> @@ -714,7 +716,7 @@ kfree(tempstr); } -static void usb_hub_events(void) +static void usb_hub_events(void*unused) { unsigned long flags; struct list_head *tmp; @@ -852,7 +854,22 @@ /* Send me a signal to get me die (for debugging) */ do { - usb_hub_events(); + /* Instead of calling usb_hub_events() + * I leave the job to keventd. That way + * new kernel threads will have keventd + * as father instead of khubd. It would + * be better but more difficult to have + * khubd taking care of its own dead + * children. + */ + struct tq_struct task; + task.routine=usb_hub_events; + schedule_task(&task); + /* I believe flushing at this point is + * the safest thing to do. It might not + * be the most efficient though. + */ + flush_scheduled_tasks(); interruptible_sleep_on(&khubd_wait); } while (!signal_pending(current)); | |