From: Oleg Nesterov <oleg@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Roland McGrath <roland@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Chris Evans <scarybeasts@gmail.com>,
David Howells <dhowells@redhat.com>,
Don Howard <dhoward@redhat.com>, Eugene Teo <eugene@redhat.com>,
Michael Kerrisk <mtk.manpages@googlemail.com>,
Tavis Ormandy <taviso@sdf.lonestar.org>,
Vitaly Mayatskikh <vmayatsk@redhat.com>,
stable@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] copy_process: fix CLONE_PARENT && ->exit_signal interaction
Date: Wed, 25 Feb 2009 22:20:39 +0100 [thread overview]
Message-ID: <20090225212039.GA11883@redhat.com> (raw)
In-Reply-To: <alpine.LFD.2.00.0902251156160.3111@localhost.localdomain>
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.
next prev parent reply other threads:[~2009-02-25 21:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-25 19:02 [PATCH 1/2] copy_process: fix CLONE_PARENT && ->exit_signal interaction Oleg Nesterov
2009-02-25 19:39 ` Roland McGrath
2009-02-25 19:48 ` Oleg Nesterov
2009-02-25 19:54 ` Roland McGrath
2009-02-25 20:06 ` Linus Torvalds
2009-02-25 21:20 ` Oleg Nesterov [this message]
2009-02-25 21:34 ` [stable] " Greg KH
2009-02-26 21:59 ` Oleg Nesterov
2009-02-26 22:12 ` Linus Torvalds
2009-02-26 22:30 ` Oleg Nesterov
2009-02-26 22:43 ` Linus Torvalds
2009-03-02 21:22 ` [PATCH] copy_process: fix CLONE_PARENT && parent_exec_id interaction Oleg Nesterov
2009-03-02 21:33 ` Linus Torvalds
2009-03-02 21:58 ` Oleg Nesterov
2009-03-09 16:45 ` David Howells
2009-03-09 18:33 ` Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090225212039.GA11883@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dhoward@redhat.com \
--cc=dhowells@redhat.com \
--cc=eugene@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@googlemail.com \
--cc=roland@redhat.com \
--cc=scarybeasts@gmail.com \
--cc=stable@kernel.org \
--cc=taviso@sdf.lonestar.org \
--cc=torvalds@linux-foundation.org \
--cc=vmayatsk@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.