DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B03D07A
Date: Wed, 13 Sep 2017 19:48:04 +0200
From: Oleg Nesterov <oleg@redhat.com>
To: =?iso-8859-1?Q?J=FCrg?= Billeter <j@bitron.ch>
Cc: Andrew Morton <akpm@linux-foundation.org>,
        Eric Biederman <ebiederm@xmission.com>, linux-kernel@vger.kernel.org,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: [PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC
Message-ID: <20170913174804.GA14752@redhat.com>
References: <20170909094008.49983-1-j@bitron.ch>
 <20170912170544.GA32121@redhat.com>
 <1505242495.5111.82.camel@bitron.ch>
 <20170913171135.GB14063@redhat.com>
 <1505323578.49783.10.camel@bitron.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1505323578.49783.10.camel@bitron.ch>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1264
Lines: 32

On 09/13, J?rg Billeter wrote:
>
> On Wed, 2017-09-13 at 19:11 +0200, Oleg Nesterov wrote:
> > On 09/12, J?rg Billeter wrote:
> > >
> > > On Tue, 2017-09-12 at 19:05 +0200, Oleg Nesterov wrote:
> > > > On 09/09, J?rg Billeter wrote:
> > > > > Unlike
> > > > > PR_SET_PDEATHSIG, this is inherited across fork to allow killing a whole
> > > > > subtree without race conditions.
> > > >
> > > > but I am still not sure this is right... at least I can't understand the
> > > > "without race conditions" above.
> > > >
> > > > IOW, the child can do prctl(PR_SET_PDEATHSIG_PROC, SIGKILL) right after fork(),
> > > > why this is not enough to kill a whole subtree without race conditions?
> > >
> > > What if the parent dies between fork() and prctl()?
> >
> > The child will be killed? Sorry, can't understand...
>
> If PR_SET_PDEATHSIG_PROC was not inherited across fork and the parent
> died between fork() and prctl(PR_SET_PDEATHSIG_PROC, SIGKILL) in the
> child, the child would not be killed.

Aah, sorry. I forgot about another oddity of pdeath_signal API...

Somehow I misread this patch as if reparent_leader() looks at
current->signal->pdeath_signal_proc, not child->signal->pdeath_signal_proc.
And to me the former makes more sense. But I won't insist.

Oleg.