Kernel zombie threads after module removal.

Kernel zombie threads after module removal.

[Clifford Kite]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2410 bytes --]

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.

---

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1277 bytes --]

--- 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));
 

Re: Kernel zombie threads after module removal.

[Greg KH]

On Mon, Feb 04, 2002 at 08:51:40PM -0600, Clifford Kite wrote:
> 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 are usb-storage zombies, and I think the latest 2.4.18-pre tree
has a fix for them.  If not, please contact the usb-storage maintainer,
as he would be the proper person for this.

thanks,

greg k-h

Kernel zombie threads after module removal.

[Christian.Gennerat]

This is very close to the problem related in 
http://lkml.org/archive/2002/2/4/368/index.html
but I have no USB. I have SCSI with aha152x_cs.o,
and after doing "cardctl eject" that removes the module,
the process scsi_eh_0  stays as zombie.
If I repeat the operation of card insert and eject,
I get  several  scsi_eh_0  zombies.

Now  with 2.4.18, but  I have got this problem with others 2.4 kernels.

Re: Kernel zombie threads after module removal.

[John Levon]

On Wed, May 29, 2002 at 09:13:05PM +0200, Christian.Gennerat wrote:

> This is very close to the problem related in 
> http://lkml.org/archive/2002/2/4/368/index.html
> but I have no USB. I have SCSI with aha152x_cs.o,
> and after doing "cardctl eject" that removes the module,
> the process scsi_eh_0  stays as zombie.

Add 

	reparent_to_init();

after the call to daemonize() in scsi_error_handler() in
drivers/scsi/scsi_error.c

Disclaimer: I don't know this code at all

regards
john

-- 
"If you look 'round the table and can't tell who the sucker is, it's you." 
	- Quiz Show