John Fremlin wrote:
>
>
> > So it seems that we must reparent the thread to init, and
> > make sure that it delivers SIGCHLD to init when it exits.
>
> Sounds good. Why isn't SIGCHLD a stronger default anyway.
mm? The caller gets to choose...
> [...]
>
> > + /* Set the exit signal to S
Andrew Morton <[EMAIL PROTECTED]> writes:
[...]
> None of these will work. The problems with globally setting
> exit_signal to SIGCHLD are that
>
> a) If the parent does waitpid(pid, status, __WCLONE), the
>waitpid will fail. request_module() does this. I don't
>know _why_ it does t
Manfred Spraul wrote:
>
> I found the problem:
>
> * init uses waitpid(-1,,), thus the __WALL flag is not set
> * without __WALL, only processes with exit_signal == SIGCHLD are reaped
> * it's impossible for user space processes to die with another
> exit_signal, forget_original_parent changes t
On Sun, 15 Apr 2001, Manfred Spraul wrote:
> Alan, which fix would you prefer:
> * init could use wait3 and set __WALL.
> * all kernel thread users could set SIGCHLD. Some already do that
> (__call_usermodehelper).
> * the kernel_thread implementations could force the exit signal to
> SIGCHLD.
>
I found the problem:
* init uses waitpid(-1,,), thus the __WALL flag is not set
* without __WALL, only processes with exit_signal == SIGCHLD are reaped
* it's impossible for user space processes to die with another
exit_signal, forget_original_parent changes the exit_signal back to
SIGCHLD ("We d
On Sat, 14 Apr 2001, Manfred Spraul wrote:
> From: "Alan Cox" <[EMAIL PROTECTED]>
> >
> > That has an implicit race, a zombie can always appear as we are
> execing init.
> > I think init wants fixing
> >
> Rod, could you boot again with the unpatched kernel and send a sigchild
> to init?
>
> #kil
Hi,
On Sat, Apr 14, 2001 at 07:53:28PM +0100, Alan Cox wrote:
> > Rod's init version (from RH 7.0) doesn't reap children that died before
> > it was started. Is that an init bug or should the kernel reap them
> > before the execve?
> I would say thats an init bug
It doesn't seem to be that simpl
From: "Alan Cox" <[EMAIL PROTECTED]>
>
> That has an implicit race, a zombie can always appear as we are
execing init.
> I think init wants fixing
>
Rod, could you boot again with the unpatched kernel and send a sigchild
to init?
#kill -CHLD 1
If I understand the init code correctly the sigchild
> Rod's init version (from RH 7.0) doesn't reap children that died before
> it was started. Is that an init bug or should the kernel reap them
> before the execve?
I would say thats an init bug
> The attached patch reaps all zombies before the execve("/sbin/init").
That has an implicit race, a
Hi Alan,
Rod's init version (from RH 7.0) doesn't reap children that died before
it was started. Is that an init bug or should the kernel reap them
before the execve?
The attached patch reaps all zombies before the execve("/sbin/init").
I also found a bug in kernel/context.c: it doesn't acquire
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.
> >
>> 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
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
[EMAIL PROTECTED] 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 threa
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 appea
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
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 d
> 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
-
To unsubscribe from this list: send the line "unsubscribe
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 buil
Alan Cox wrote:
>
> > 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:
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 app
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
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? ze
23 matches
Mail list logo
