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.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
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
On Mon, Mar 16, 2015 at 03:14:14PM -0700, Thiago Macieira 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.
Minor nit: CLONE_AUTOREAP makes the process autoreap and nobody can wait
on it, but if you pass SIGCHLD or some other exit signal to clone then
you'll still get that signal.
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().
Right.
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.
Hrm? That isn't the semantics we implemented; you'll *always* get an
exit notification via the clonefd if you have it open, with or without
autoreap and whether or not a wait has occurred yet. And reading from
the clonefd does not serve as a wait; if you don't pass CLONE_AUTOREAP,
you'll still need to wait on the process.
- Josh Triplett
On Mon, Mar 16, 2015 at 03:36:16PM -0700, Kees Cook wrote:
On Mon, Mar 16, 2015 at 3:14 PM, Thiago Macieira
[off-list ref] wrote:
quoted
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?)
This doesn't actually work like a pipe; the details aren't "written" to
the fd. The data is generated at read time, and if you never read,
that's fine. There's no semantic meaning attached to reading from the
clonefd; you still have to wait on the process if you don't pass
CLONE_AUTOREAP. (Or you can block SIGCHLD or use SA_NOCLDWAIT, if you
control the calling process's signal handling; AUTOREAP just lets you
avoid interacting with the calling process's signal handling.)
See my previous response for the rest.
- Josh Triplett
On Monday 16 March 2015 16:29:49 josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org wrote:
quoted
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.
Hrm? That isn't the semantics we implemented; you'll *always* get an
exit notification via the clonefd if you have it open, with or without
autoreap and whether or not a wait has occurred yet. And reading from
the clonefd does not serve as a wait; if you don't pass CLONE_AUTOREAP,
you'll still need to wait on the process.
Ah, I see what you're saying. Ok, I stand corrected: a child without
CLONE_AUTOREAP must be wait()ed on and whoever waits on it will get
information. In addition to that, the information is available on the clonefd
and it can happen at any time, before or after the wait().
In the case of an orphaned child, the file descriptor will close, that's all.
No modification is necessary to init.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
From: David Drysdale <hidden> Date: 2015-03-23 14:12:34
On Mon, Mar 16, 2015 at 11:29 PM, [off-list ref] wrote:
On Mon, Mar 16, 2015 at 03:14:14PM -0700, Thiago Macieira wrote:
quoted
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.
Minor nit: CLONE_AUTOREAP makes the process autoreap and nobody can wait
on it, but if you pass SIGCHLD or some other exit signal to clone then
you'll still get that signal.
Quick query: does CLONE_AUTOREAP also affect waiting for non-exit
events (i.e. WUNTRACED / WCONTINUED), by original parent and/or ptracer?
On Mon, Mar 23, 2015 at 02:12:34PM +0000, David Drysdale wrote:
On Mon, Mar 16, 2015 at 11:29 PM, [off-list ref] wrote:
quoted
On Mon, Mar 16, 2015 at 03:14:14PM -0700, Thiago Macieira wrote:
quoted
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.
Minor nit: CLONE_AUTOREAP makes the process autoreap and nobody can wait
on it, but if you pass SIGCHLD or some other exit signal to clone then
you'll still get that signal.
Quick query: does CLONE_AUTOREAP also affect waiting for non-exit
events (i.e. WUNTRACED / WCONTINUED), by original parent and/or ptracer?
It shouldn't, no. You can't wait on the process to exit (you'll get
-ECHLD after it wakes up), but you can wait on it to continue or
similar; none of the autoreap changes should affect that.
- Josh Triplett