On Mon, Mar 16, 2015 at 02:44:20PM -0700, Kees Cook wrote: > On Sun, Mar 15, 2015 at 12:59 AM, Josh Triplett <josh@xxxxxxxxxxxxxxxx> wrote: > > - Make poll on a CLONE_FD for an exited task also return POLLHUP, for > > compatibility with FreeBSD's pdfork. Thanks to David Drysdale for calling > > attention to pdfork. > > I think POLLHUP should be mentioned in the manpage (now it only > mentions POLLIN). Added for v3. > > CLONE_FD > > Return a file descriptor associated with the new process, stor‐ > > ing it in location clonefd in the parent's address space. When > > the new process exits, the file descriptor will become available > > for reading. > > > > Unlike using signalfd(2) for the SIGCHLD signal, the file > > descriptor returned by clone4() with the CLONE_FD flag works > > even with SIGCHLD unblocked in one or more threads of the parent > > process, allowing the process to have different handlers for > > different child processes, such as those created by a library, > > without introducing race conditions around process-wide signal > > handling. > > > > clonefd_flags may contain the following additional flags for use > > with CLONE_FD: > > > > > > 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...) Whether the parent gets SIGCHLD is determined only by what signal you request in clone; if you clone with CLONE_FD | SIGCHLD (or CLONE_AUTOREAP | CLONE_FD | SIGCHLD), you'll get notification via both clonefd (if you have one) and signal (if you have a handler). If you pass a 0 signal (just CLONE_FD or CLONE_AUTOREAP | CLONE_FD), you'll receive no signal, only the notification via clonefd. Independently, if you have CLONE_AUTOREAP set, the process will autoreap. Those are all orthogonal now. If you close the clonefd, nothing special happens other than a put_task_struct. While this is conceptually somewhat like a pipe, the data is actually generated at read time, so the task exit doesn't care whether there's a live clonefd or not. (Or, in the future, if there are multiple live clonefds for the same process.) > Looks promising! Thanks! And thanks for catching the manpage issue. I'd definitely welcome any comments you have on the implementation as well. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html