linux-kernel - Re: [PATCH v3 20/20] signal: Don't restart fork when signals come in.

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]

Date:   Thu, 26 Jul 2018 17:55:47 +0200
From:   Oleg Nesterov <oleg@...hat.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Wen Yang <wen.yang99@....com.cn>, majiang <ma.jiang@....com.cn>
Subject: Re: [PATCH v3 20/20] signal: Don't restart fork when signals come in.

On 07/26, Eric W. Biederman wrote:
>
> Are the earlier patches looking ok to you?

I obviously like 1-15.

"[PATCH 16/20] fork: Move and describe why the code examines PIDNS_ADDING"
is "interesting". I mean it is fine, but at the end of this series it doesn't
matter what we check first, PIDNS_ADDING or fatal_signal_pending() - restart
is not possible in both cases.

As for 17-20... Yes I am biased. But I still think the simple approach I tried
to propose from the very beginning is better. At least simpler, in that you do
not need to worry about all these special cases/reasons for signal_pending().

And you can not imagine how much I hate "[PATCH 19/20] fork: Have new threads
join on-going signal group stops" ;) Because I spent HOURS looking at this trivial
patch and I am still not sure...

To clarify, the CLONE_THREAD with JOBCTL_STOP_PENDING case is simple, I am mostly
worried about JOBCTL_TRAP_STOP/etc with or without CLONE_THREAD, this adds some
subtle changes but unfortunately I failed to find something wrong so I can't argue.

Oleg.