Re: [RFC PATCH] kernel/fork: fix CLONE_CHILD_CLEARTID regression in nscd

[Oleg Nesterov]

On 08/19, Michal Hocko wrote:
>
> On Fri 12-08-16 11:41:13, Michal Hocko wrote:
> > On Wed 03-08-16 23:08:04, Oleg Nesterov wrote:
> > >
> > > So if we want this change, why we can't simply do
> > >
> > > 	-	if (!(tsk->flags & PF_SIGNALED) &&
> > > 	+	if (!(tsk->signal->flags & SIGNAL_GROUP_COREDUMP) &&
> > >
> > > ?
> >
> > This is what I had initially. But then the comment above the check made
> > me worried that the parent of vforked child might get confused if the
> > flag is cleared.

I don't think the child can be confused... At least I can't imagine how
this can happen.

Anyway, I objected because the tsk->vfork != NULL check was wrong, in this
case this tsk is vforke'd child, not parent.

> So should I drop the vfork check and repost

Probably yes. At least the SIGNAL_GROUP_COREDUMP will match the comment.

> or we do not care about this
> "regression"

Honestly, I do not know ;) Personally, I am always scared when it comes
to the subtle changes like this, you can never know what can be broken.
And note that it can be broken 10 years later, like it happened with
nscd ;)

But if you send the s/PF_SIGNALED/SIGNAL_GROUP_COREDUMP/ change I will
ack it ;) Even if it won't really fix this nscd problem (imo), because
I guess nscd wants to reset ->clear_child_tid even if the signal was
sig_kernel_coredump().

Oleg.