linux-kernel - Re: [RESEND][RFC PATCH v2] waitfd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090110155720.GA10954@redhat.com>
Date:	Sat, 10 Jan 2009 16:57:20 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Scott James Remnant <scott@...onical.com>
Cc:	Roland McGrath <roland@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	Casey Dahlin <cdahlin@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Davide Libenzi <davidel@...ilserver.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [RESEND][RFC PATCH v2] waitfd

On 01/10, Scott James Remnant wrote:
>
> On Wed, 2009-01-07 at 12:53 -0800, Roland McGrath wrote:
>
> > New syscall should have gone to linux-api, I think.
> >
> > Do we really need another one for this?  How about using signalfd plus
> > setting the child's exit_signal to a queuing (SIGRTMIN+n) signal instead of
> > SIGCHLD?  It's slightly more magical for the userland process to know to do
> > that (fork -> clone SIGRTMIN).  But compared to adding a syscall we don't
> > really have to add, maybe better.
> >
> This wouldn't help the init daemon case:
>
> - the exit_signal is set on the child, not on the parent.
>
>   While the init daemon could clone() every new process and set
>   exit_signal, this would not be set for processes reparented to init.
>
>   Even if we had a new syscall to change the exit_signal of a given
>   process, *and* had the init reparent notification patch, this still
>   wouldn't be sufficient; you'd have a race condition between the time
>   you were notified of the reparent, and the time you set exit_signal,
>   in which the child could die.
>
>   Since exit_signal is always reset to SIGCHLD before reparenting, this
>   could be done by resetting it to a different signal; but at this point
>   we're getting into a rather twisty method full of traps.
>
> - exit_signal is reset to SIGCHLD on exec().
>
>   Pretty much a plan-killer ;)

I can't understand why should we change ->exit_signal if we want to
use signalfd. Yes, SIGCHLD is not rt. So what?

We do not need multiple signals in queue if we want to reap multiple
zombies. Once we have a single SIGCHLD (reported by signalfd or
whatever) we can do do_wait(WNOHANG) in a loop.

Confused.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/