Thread (7 messages) 7 messages, 5 authors, 2015-03-23

Re: [PATCH v2 0/7] CLONE_FD: Task exit notification via file descriptor

From: Kees Cook <hidden>
Date: 2015-03-16 22:36:16
Also in: linux-fsdevel, lkml

On Mon, Mar 16, 2015 at 3:14 PM, Thiago Macieira
[off-list ref] wrote:
On Monday 16 March 2015 14:44:20 Kees Cook wrote:
quoted
quoted
              O_CLOEXEC
                     Set  the  close-on-exec  flag on the new file
descriptor. See the description of the O_CLOEXEC flag in open(2)  for
reasons why this may be useful.
This begs the question: what happens when all CLONE_FD fds for a
process are closed? Will the parent get SIGCHLD instead, will it
auto-reap, or will it be un-wait-able (I assume not this...)
Depends on CLONE_AUTOREAP. If it's on, then no one gets SIGCHLD, no one can
wait() on it and the process autoreaps itself.

If it's no active, then the old rules apply: parent gets SIGCHILD and can
wait(). If the parent exited first, then the child gets reparented to init,
which can do the wait().

A child without CLONE_AUTOREAP should be wait()able. If it gets wait()ed
before the clonefd is read, the clonefd() will return a 0 read. If it gets
read before wait, then wait() reaps another child or returns -ECHILD. That's
no different than two threads doing simultaneous wait() on the same child.
Cool. I think detailing this in the manpage would be helpful.

And just so I understand the races here, what happens in CLONE_FD
(without CLONE_AUTOREAP) case where the child dies, but the parent
never reads from the CLONE_FD fd, and closes it (or dies)? Will the
modes switch that late in the child's lifetime? (i.e. even though the
details were written to the fd, they were never read, yet it'll still
switch and generate a SIGCHLD, etc?)

Thanks!

-Kees

-- 
Kees Cook
Chrome OS Security
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help