From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758960AbZBYVYc (ORCPT ); Wed, 25 Feb 2009 16:24:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752132AbZBYVYX (ORCPT ); Wed, 25 Feb 2009 16:24:23 -0500 Received: from mx2.redhat.com ([66.187.237.31]:56816 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751988AbZBYVYW (ORCPT ); Wed, 25 Feb 2009 16:24:22 -0500 Date: Wed, 25 Feb 2009 22:20:39 +0100 From: Oleg Nesterov To: Linus Torvalds Cc: Roland McGrath , Andrew Morton , Alan Cox , Chris Evans , David Howells , Don Howard , Eugene Teo , Michael Kerrisk , Tavis Ormandy , Vitaly Mayatskikh , stable@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] copy_process: fix CLONE_PARENT && ->exit_signal interaction Message-ID: <20090225212039.GA11883@redhat.com> References: <20090225190211.GA7445@redhat.com> <20090225193927.1ED25FC3DA@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/25, Linus Torvalds wrote: > > > As I think I said before, I don't really know what the actual use case is > > for CLONE_PARENT without CLONE_THREAD. So it's easy to approve changing > > its behavior, but I do vaguely worry about who expected what behavior before. > > I think changing it is wrong. Perhaps. As I said, I don't know what is the expected behaviour. And in fact I can't think of the "obviously good" behaviour. > I can easily see somebody using CLONE_PARENT to get the correct getppid > semantics in the thread, and then setting the signal to zero to not make > the parent see the thread go away. ->exit_signal == 0 doesn't mean the thread silently goes away, it becomes a zombie (even if ->parent ignores SIGCHLD). We don't send the signal, but that is all. And if ->parent execs, we reset ->exit_signal to SIGCHLD anyway. > So at the very least it should accept zero for "no signal". perhaps. I don't know. But I am not sure this is always right. > And quite > frankly, it would be good to try to see if there are other alternatives. Agreed. I thought about checking ->xxx_exec_id's in copy_process(), but doesn't look very nice... (can't resist... hopefully now it is clear this should have beeen discussed outside of the closed lists from the very beginning ;) Oleg.