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 S1758317AbcHCVIN (ORCPT <rfc822;w@1wt.eu>);
	Wed, 3 Aug 2016 17:08:13 -0400
Received: from mx1.redhat.com ([209.132.183.28]:36232 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1756229AbcHCVIL (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 3 Aug 2016 17:08:11 -0400
Date: Wed, 3 Aug 2016 23:08:04 +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>, Michal Hocko <mhocko@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: <20160803210804.GA11549@redhat.com>
References: <1470039287-14643-1-git-send-email-mhocko@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1470039287-14643-1-git-send-email-mhocko@kernel.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 03 Aug 2016 21:08:07 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

sorry for delay, I am travelling till the end of the week.

On 08/01, Michal Hocko wrote:
>
> fec1d0115240 ("[PATCH] Disable CLONE_CHILD_CLEARTID for abnormal exit")

almost 10 years ago ;)

> has caused a subtle regression in nscd which uses CLONE_CHILD_CLEARTID
> to clear the nscd_certainly_running flag in the shared databases, so
> that the clients are notified when nscd is restarted.

So iiuc with this patch nscd_certainly_running should be cleared even if
ncsd was killed by !sig_kernel_coredump() signal, right?

> We should also check for vfork because
> this is killable since d68b46fe16ad ("vfork: make it killable").

Hmm, why? Can't understand... In any case this check doesn't look right, the
comment says "a killed vfork parent" while tsk->vfork_done != NULL means it
is a vforked child.

So if we want this change, why we can't simply do

	-	if (!(tsk->flags & PF_SIGNALED) &&
	+	if (!(tsk->signal->flags & SIGNAL_GROUP_COREDUMP) &&

?

And I think PF_SIGNALED must die in any case... but this is off-topic.

Oleg.