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] [day] [month] [year] [list]

Message-ID: <20160823160337.GA25099@dhcp22.suse.cz>
Date:   Tue, 23 Aug 2016 18:03:37 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Oleg Nesterov <oleg@...hat.com>
Cc:     linux-mm@...ck.org, LKML <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        William Preston <wpreston@...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

On Tue 23-08-16 17:27:11, Oleg Nesterov wrote:
> On 08/19, Michal Hocko wrote:
[...]
> > 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.

If _you_ are scarred (after so many years of permanent exposure to this
code) then try to imagine how I am scarred when touching anything in
this area...

> 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 ;)

OK, I will repost

> 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().

Come on, have you ever seen this fine piece of software crashing?
But more seriously, I wouldn't give a damn because nscd is usually the
first thing I disable on my systems but there seem to be people who
would like to use this persistence thingy and even service restart will
break it. So I think we should plug this hole.

Anyway thanks for your review and feedback. As always it is really
appreciated!
-- 
Michal Hocko
SUSE Labs