Messages in this thread | | | Subject | Re: [PATCH] make fork() atomic wrt pgrp/session signals | From | (Eric W. Biederman) | Date | Thu, 16 Mar 2006 09:27:31 -0700 |
| |
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> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |