8139too: defunct threads

8139too: defunct threads

[Rod Stewart]

Hello,

Using the 8139too driver, 0.9.15c, we have noticed that we get a defunct
thread for each device we have; if the driver is built into the kernel.
If the driver is built as a module, no defunct threads appear.

This has happened with any 2.4 kernel we've used, up to and including
2.4.3.

Below is the output from a custom board (but the problem also shows up
with a standard PCI card with RTL-8139B) with three RealTek RTL8139
chipsets on it.

[root@stewart-nw34 /root]# ps uaxwwww|grep eth
root        14  0.0  0.0     0    0 ?  Z    13:39   0:00 [eth0  <defunct>]
root        15  0.0  0.0     0    0 ?  Z    13:39   0:00 [eth1  <defunct>]
root        16  0.0  0.0     0    0 ?  Z    13:39   0:00 [eth2  <defunct>]
root       240  0.0  0.0     0    0 ?        SW   13:39   0:00 [eth0]
root       572  0.0  0.0     0    0 pts/1    SW   13:49   0:00 [eth1]
root       538  0.0  0.4  1216  460 pts/0    S    13:41   0:00 grep eth

8139too Fast Ethernet driver 0.9.15c loaded
PCI: Enabling device 00:05.0 (0000 -> 0003)
PCI: Assigned IRQ 6 for device 00:05.0
PCI: Setting latency timer of device 00:05.0 to 64
eth0: RealTek RTL8139 Fast Ethernet at 0xc7800000, 00:10:57:01:00:19,
	IRQ 6
eth0:  Identified 8139 chip type 'RTL-8139C'
PCI: Enabling device 00:09.0 (0000 -> 0003)
PCI: Assigned IRQ 6 for device 00:09.0
PCI: Setting latency timer of device 00:09.0 to 64
eth1: RealTek RTL8139 Fast Ethernet at 0xc7802100, 00:10:57:02:00:19,
	IRQ 6
eth1:  Identified 8139 chip type 'RTL-8139C'
PCI: Enabling device 00:0a.0 (0000 -> 0003)
PCI: Assigned IRQ 6 for device 00:0a.0
PCI: Setting latency timer of device 00:0a.0 to 64
eth2: RealTek RTL8139 Fast Ethernet at 0xc7804200, 00:10:57:03:00:19,
	IRQ 6
eth2:  Identified 8139 chip type 'RTL-8139C'


I'm not certain if this is supposed to be expected behaviour or not, if it
is we'll tell QA to ignore it.

Thanks,
-Rms

Re: 8139too: defunct threads

[Andrew Morton]

Rod Stewart wrote:
> 
> Hello,
> 
> Using the 8139too driver, 0.9.15c, we have noticed that we get a defunct
> thread for each device we have; if the driver is built into the kernel.
> If the driver is built as a module, no defunct threads appear.

What is the parent PID for the defunct tasks?  zero?

<slaps head> swapper doesn't know how to reap children, and
AFAIK there's no way for a kernel thread to fully clean itself
up.  This is always done by the parent.

ho-hum.  Jeff, I think the best fix here is to bite the
bullet and write kernel_daemon(), which will delegate
thread creation to keventd, which is the only thing
we have which reaps zombies.  Any better ideas?

Re: 8139too: defunct threads

[Alan Cox]

> <slaps head> swapper doesn't know how to reap children, and
> AFAIK there's no way for a kernel thread to fully clean itself
> up.  This is always done by the parent.

Make daemonize() move threads with parent 0 to parent 1

Re: 8139too: defunct threads

[Andrew Morton]

Alan Cox wrote:
> 
> > <slaps head> swapper doesn't know how to reap children, and
> > AFAIK there's no way for a kernel thread to fully clean itself
> > up.  This is always done by the parent.
> 
> Make daemonize() move threads with parent 0 to parent 1

Reparenting would require diving inside this lot:

        /* 
         * pointers to (original) parent process, youngest child, younger sibling,
         * older sibling, respectively.  (p->father can be replaced with 
         * p->p_pptr->pid)
         */
        struct task_struct *p_opptr, *p_pptr, *p_cptr, *p_ysptr, *p_osptr;
        struct list_head thread_group;

plus maybe rewriting pgrps, sessions, gids, etc.  Challenging.

Plus it would mean that the kernel requires, for its
correct operation, that process "1" is a child reaper.
Is this a good thing?

Re: 8139too: defunct threads

[Alan Cox]

> Plus it would mean that the kernel requires, for its
> correct operation, that process "1" is a child reaper.
> Is this a good thing?

That is already required. The rest of the reparenting functionality is also
in kernel/exit.c already

Re: 8139too: defunct threads

[Rod Stewart]

On Thu, 12 Apr 2001, Andrew Morton wrote:
> Rod Stewart wrote:
> >
> > Hello,
> >
> > Using the 8139too driver, 0.9.15c, we have noticed that we get a defunct
> > thread for each device we have; if the driver is built into the kernel.
> > If the driver is built as a module, no defunct threads appear.
>
> What is the parent PID for the defunct tasks?  zero?

According to ps, 1

[root@stewart-nw34 networking]# ps alexw
  F   UID PID  PPID PRI  NI   VSZ  RSS WCHAN  STAT TTY TIME  COMMAND
044     0  14     1   9   0     0    0 do_exi Z    ?  0:00 [eth0 <defunct>]
044     0  15     1   9   0     0    0 do_exi Z    ?  0:00 [eth1 <defunct>]
044     0  16     1   9   0     0    0 do_exi Z    ?  0:00 [eth2 <defunct>]
040     0 240     1   9   0     0    0 rtl813 SW   ?  0:00 [eth0]

-Rms

Re: 8139too: defunct threads

[Andrew Morton]

Rod Stewart wrote:
> 
> On Thu, 12 Apr 2001, Andrew Morton wrote:
> > Rod Stewart wrote:
> > >
> > > Hello,
> > >
> > > Using the 8139too driver, 0.9.15c, we have noticed that we get a defunct
> > > thread for each device we have; if the driver is built into the kernel.
> > > If the driver is built as a module, no defunct threads appear.
> >
> > What is the parent PID for the defunct tasks?  zero?
> 
> According to ps, 1

Ah.  Of course.  All (or most) kernel initialisation is
done by PID 1.  Search for "kernel_thread" in init/main.c

So it seems that in your setup, process 1 is not reaping
children, which is why this hasn't been reported before.
Is there something unusual about your setup?

Re: 8139too: defunct threads

[Rod Stewart]

On Thu, 12 Apr 2001, Andrew Morton wrote:
> Rod Stewart wrote:
> >
> > On Thu, 12 Apr 2001, Andrew Morton wrote:
> > > Rod Stewart wrote:
> > > >
> > > > Hello,
> > > >
> > > > Using the 8139too driver, 0.9.15c, we have noticed that we get a defunct
> > > > thread for each device we have; if the driver is built into the kernel.
> > > > If the driver is built as a module, no defunct threads appear.
> > >
> > > What is the parent PID for the defunct tasks?  zero?
> >
> > According to ps, 1
>
> Ah.  Of course.  All (or most) kernel initialisation is
> done by PID 1.  Search for "kernel_thread" in init/main.c
>
> So it seems that in your setup, process 1 is not reaping
> children, which is why this hasn't been reported before.
> Is there something unusual about your setup?

One box is standard PIII with RH 7.0, the other is a custom Crusoe TM5400
board.  But from further investigation it appears to be a kernel config
option.  As I've got a 2.4.0 kernel which has very little compiled in and
not showing the problem and another kernel which has many more networking
options built in and showing the problem.  I've seen this problem
since 2.4.0.test11.

I'll send a note once I find the config option which is causing this,
probably tomorrow.

Thanks,
-Rms

Re: 8139too: defunct threads

[Andrew Morton]

Rod Stewart wrote:
> 
> On Thu, 12 Apr 2001, Andrew Morton wrote:
> > Is there something unusual about your setup?
> 
> One box is standard PIII with RH 7.0, the other is a custom Crusoe TM5400
> board.  But from further investigation it appears to be a kernel config
> option.  As I've got a 2.4.0 kernel which has very little compiled in and
> not showing the problem and another kernel which has many more networking
> options built in and showing the problem.  I've seen this problem
> since 2.4.0.test11.
> 

Sorry.  I meant: what is process 1 on this machine?  Is it not
the normal init?  If not, then according to Alan, the fault
lies with your userspace.  Kernel requires that PID 1 reap
children.

Re: 8139too: defunct threads

[Rod Stewart]

On Thu, 12 Apr 2001, Andrew Morton wrote:
> Rod Stewart wrote:
> >
> > On Thu, 12 Apr 2001, Andrew Morton wrote:
> > > Is there something unusual about your setup?
> >
> > One box is standard PIII with RH 7.0, the other is a custom Crusoe TM5400
> > board.  But from further investigation it appears to be a kernel config
> > option.  As I've got a 2.4.0 kernel which has very little compiled in and
> > not showing the problem and another kernel which has many more networking
> > options built in and showing the problem.  I've seen this problem
> > since 2.4.0.test11.
> >
>
> Sorry.  I meant: what is process 1 on this machine?  Is it not
> the normal init?  If not, then according to Alan, the fault
> lies with your userspace.  Kernel requires that PID 1 reap
> children.

Yes, it is the normal init on both boxes.

-Rms

Re: 8139too: defunct threads

[Rod Stewart]

On Thu, 12 Apr 2001, Andrew Morton wrote:
> Rod Stewart wrote:
> >
> > On Thu, 12 Apr 2001, Andrew Morton wrote:
> > > Rod Stewart wrote:
> > > >
> > > > Hello,
> > > >
> > > > Using the 8139too driver, 0.9.15c, we have noticed that we get a defunct
> > > > thread for each device we have; if the driver is built into the kernel.
> > > > If the driver is built as a module, no defunct threads appear.
> > >
> > > What is the parent PID for the defunct tasks?  zero?
> >
> > According to ps, 1
>
> Ah.  Of course.  All (or most) kernel initialisation is
> done by PID 1.  Search for "kernel_thread" in init/main.c
>
> So it seems that in your setup, process 1 is not reaping
> children, which is why this hasn't been reported before.
> Is there something unusual about your setup?

I found the difference which causes this.  If I build my kernel with
IP_PNP (IP: kernel level autoconfiguration) support I get a defunt thread
for each 8139too device.  If I don't build with IP_PNP support I don't get
any, defunct ethernet threads.

This make any sense?  Here is the relevant diff from a working config to a
bad one:
[root@stewart-nw34 conf]# diff -u config-p5-good config-p6-bad
--- config-p5-good      Fri Apr 13 16:07:10 2001
+++ config-p6-bad       Fri Apr 13 16:12:21 2001
@@ -173,7 +173,9 @@
# CONFIG_IP_ROUTE_TOS is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_ROUTE_LARGE_TABLES is not set
-# CONFIG_IP_PNP is not set
+CONFIG_IP_PNP=y
+# CONFIG_IP_PNP_BOOTP is not set
+# CONFIG_IP_PNP_RARP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
# CONFIG_NET_IPGRE_BROADCAST is not set

Thanks,
-Rms

Re: 8139too: defunct threads

[David Woodhouse]

andrewm@uow.edu.au said:
>  ho-hum.  Jeff, I think the best fix here is to bite the bullet and
> write kernel_daemon(), which will delegate thread creation to keventd,
> which is the only thing we have which reaps zombies.  Any better
> ideas?

Yes. Let init do it, as God intended. Why reap threads in the kernel when 
they could just reparent themselves as children of pid 1?

--
dwmw2

Re: 8139too: defunct threads

[Manfred Spraul]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

>> Ah. Of course. All (or most) kernel initialisation is
>> done by PID 1. Search for "kernel_thread" in init/main.c
>>
>> So it seems that in your setup, process 1 is not reaping
>> children, which is why this hasn't been reported before.
>> Is there something unusual about your setup?

> I found the difference which causes this. If I build my kernel with
> IP_PNP (IP: kernel level autoconfiguration) support I get a defunt
> thread for each 8139too device. If I don't build with IP_PNP
> support I don't get any, defunct ethernet threads.

Does init(8) reap children that died before it was spawned? I assume
that the defunct tasks were there _before_ init was spawned.

Perhaps init() [in linux/init/main.c] should reap all defunct tasks
before the execve("/sbin/init").

I've attached an untested patch, could you try it?

--
    Manfred


[-- Attachment #2: patch-main.dat --]
[-- Type: application/octet-stream, Size: 423 bytes --]

--- main.c	Fri Mar 30 15:42:49 2001
+++ /pub/home/manfred/main.c	Sat Apr 14 15:56:26 2001
@@ -777,6 +777,13 @@
 
 	(void) dup(0);
 	(void) dup(0);
+
+	while (waitpid(-1, (unsigned int *)0, __WALL|WNOHANG) > 0)
+		;
+	spin_lock_irq(&current->sigmask_lock);
+	flush_signals(curtask);
+	recalc_sigpending(curtask);
+	spin_lock_irq(&current->sigmask_lock);
 	
 	/*
 	 * We try each of these until one succeeds.

Re: 8139too: defunct threads

[Rod Stewart]

On Sat, 14 Apr 2001, Manfred Spraul wrote:

> >> Ah. Of course. All (or most) kernel initialisation is
> >> done by PID 1. Search for "kernel_thread" in init/main.c
> >>
> >> So it seems that in your setup, process 1 is not reaping
> >> children, which is why this hasn't been reported before.
> >> Is there something unusual about your setup?
>
> > I found the difference which causes this. If I build my kernel with
> > IP_PNP (IP: kernel level autoconfiguration) support I get a defunt
> > thread for each 8139too device. If I don't build with IP_PNP
> > support I don't get any, defunct ethernet threads.
>
> Does init(8) reap children that died before it was spawned? I assume
> that the defunct tasks were there _before_ init was spawned.
>
> Perhaps init() [in linux/init/main.c] should reap all defunct tasks
> before the execve("/sbin/init").
>
> I've attached an untested patch, could you try it?

Yes, that fixes my problem.  No more defunct eth? processes when IP_PNP is
compiled in.  With the fix you said to the patch; replacing curtask with
current.

Thanks,
-Rms