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: <alpine.DEB.1.10.0812122025180.27751@alien.or.mcafeemobile.com>
Date:	Fri, 12 Dec 2008 20:29:31 -0800 (PST)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Scott James Remnant <scott@...split.com>
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 Fri, 12 Dec 2008, Scott James Remnant wrote:

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

And how about this?

	sfd = signalfd(SIGCHLD);
	for (;;) {
		poll(sfd, POLLIN);
		while ((pid = waitpid(0, &status, WNOHANG)) != -1)
			process_child_death(pid);
	}



- Davide


--
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/