linux-kernel - Re: [RFC PATCH] kernel/fork: fix CLONE_CHILD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160803210804.GA11549@redhat.com>
Date:	Wed, 3 Aug 2016 23:08:04 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Michal Hocko <mhocko@...nel.org>
Cc:	linux-mm@...ck.org, LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	William Preston <wpreston@...e.com>,
	Michal Hocko <mhocko@...e.com>,
	Roland McGrath <roland@...k.frob.com>,
	Andreas Schwab <schwab@...e.com>
Subject: Re: [RFC PATCH] kernel/fork: fix CLONE_CHILD_CLEARTID regression in
 nscd

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.