From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755554AbbE2Hnu (ORCPT ); Fri, 29 May 2015 03:43:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38300 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753551AbbE2Hnl (ORCPT ); Fri, 29 May 2015 03:43:41 -0400 Message-ID: <556818A7.3030804@redhat.com> Date: Fri, 29 May 2015 09:43:35 +0200 From: Florian Weimer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Josh Triplett , Al Viro , Andrew Morton , Andy Lutomirski , Ingo Molnar , Kees Cook , Oleg Nesterov , "Paul E. McKenney" , "H. Peter Anvin" , Rik van Riel , Thomas Gleixner , Michael Kerrisk , Thiago Macieira , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH v2 0/7] CLONE_FD: Task exit notification via file descriptor References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/15/2015 08:59 AM, Josh Triplett wrote: > This patch series introduces a new clone flag, CLONE_FD, which lets the caller > receive child process exit notification via a file descriptor rather than > SIGCHLD. CLONE_FD makes it possible for libraries to safely launch and manage > child processes on behalf of their caller, *without* taking over process-wide > SIGCHLD handling (either via signal handler or signalfd). > > Note that signalfd for SIGCHLD does not suffice here, because that still > receives notification for all child processes, and interferes with process-wide > signal handling. It has been suggested (e.g., ) that you can use the existing clone(2) without specifying SIGCHLD to create a new process. The resulting child process is not supposed to show up in wait(2), only in a waitpid(2) (or similar) explicitly specifying the PID. Is this not the case? -- Florian Weimer / Red Hat Product Security