lkml.org 
[lkml]   [2002]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectKernel 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));
\
 
 \ /
  Last update: 2005-03-22 13:23    [W:0.037 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site