From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753756AbcHWP2n (ORCPT <rfc822;w@1wt.eu>);
        Tue, 23 Aug 2016 11:28:43 -0400
Received: from mx1.redhat.com ([209.132.183.28]:51108 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752302AbcHWP2X (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 23 Aug 2016 11:28:23 -0400
Date: Tue, 23 Aug 2016 17:27:11 +0200
From: Oleg Nesterov <oleg@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        William Preston <wpreston@suse.com>,
        Roland McGrath <roland@hack.frob.com>,
        Andreas Schwab <schwab@suse.com>
Subject: Re: [RFC PATCH] kernel/fork: fix CLONE_CHILD_CLEARTID regression
        in nscd
Message-ID: <20160823152711.GA4067@redhat.com>
References: <1470039287-14643-1-git-send-email-mhocko@kernel.org> <20160803210804.GA11549@redhat.com> <20160812094113.GE3639@dhcp22.suse.cz> <20160819132511.GH32619@dhcp22.suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160819132511.GH32619@dhcp22.suse.cz>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 23 Aug 2016 15:27:36 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.