Re: [PATCH] make fork() atomic wrt pgrp/session signals

[ebiederm@xmission.com (Eric W. Biederman)]

Oleg Nesterov <oleg@tv-sign.ru> writes:

> Eric W. Biederman wrote:
>>
>> Ok. SUSV3/Posix is clear, fork is atomic with respect
>> to signals.  Either a signal comes before or after a
>> fork but not during. (See the rationale section).
>> http://www.opengroup.org/onlinepubs/000095399/functions/fork.html
>>
>> The tasklist_lock does not stop forks from adding to a process
>> group. The forks stall while the tasklist_lock is held, but a fork
>> that began before we grabbed the tasklist_lock simply completes
>> afterwards, and the child does not receive the signal.
>
> This also means that SIGSTOP or sig_kernel_coredump() signal can't
> be delivered to pgrp/session reliably.
>
> With this patch copy_process() returns -ERESTARTNOINTR when it
> detects a pending signal, fork() will be restarted transparently
> after handling the signals.
>
> This patch also deletes now unneeded "group_stop_count > 0" check,
> copy_process() can no longer succeed while group stop in progress.
>
> Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>

Looks like what we discussed and I can't see any flaws with it.

Acked-By: Eric Biederman <ebiederm@xmission.com>