linux-kernel - Re: [RFC PATCH] waitfd: file descriptor to wait on child processes

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: <1229124491.12618.5.camel@warcraft>
Date:	Fri, 12 Dec 2008 15:28:11 -0800
From:	Scott James Remnant <scott@...split.com>
To:	Davide Libenzi <davidel@...ilserver.org>
Cc:	Casey Dahlin <cdahlin@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] waitfd: file descriptor to wait on child processes

On Tue, 2008-12-09 at 11:41 -0800, Davide Libenzi wrote:

> On Tue, 9 Dec 2008, Casey Dahlin wrote:
> 
> > Linux already has signalfd, timerfd, and eventfd to expose signals, timers,
> > and events via a file descriptor. This patch is a working prototype for a
> > fourth: waitfd. It pretty much does what the name suggests: reading from it
> > yields a series of status ints (as would be written into the second argument
> > of waitpid) for child processes that have changed state. It takes essentially
> > the same arguments as waitpid (for now) and supports the same set of features.
> > 
> What's wrong in having a signalfd on SIGCHLD, than doing waitpid() once 
> you get the signal?
> 
Because SIGCHLD isn't a POSIX realtime signal, only one copy of it will
be queued at any one time -- even with signalfd(), and even though they
have different (useful) siginfo_t.

So if you have three children die in rapid succession, you only get the
siginfo for the first one.  Thus you still have to call
waitid()/waitpid() in a loop, and wait on everything.

Could the fact that you don't get signalfd notification of the
additional signals be considered a bug?  Or possibly a useful additional
feature?

If we were able to read all the queued SIGCHLD signals with signalfd
(preserving the one pending only behaviour of ordinary delivery), then a
loop like the following would be possible:

  sigemptyset (&mask);
  sigaddset (&mask, SIGCHLD);

  sfd = signalfd (-1, &mask, 0);

  for (;;) {
    read (sfd, &fdsi, sizeof (struct signalfd_siginfo));

    waitpid (fdsi.ssi_pid, 0, 0);
  }

So you only need to wait for each one individually.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)