[Bug libc/10354] posix_spawn should use vfork() in more cases than presently

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=10354

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #9 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Rich Felker from comment #8)
> Using clone with CLONE_VM and a new stack/start-function solves most of the
> insurmountable problems with vfork that make it unsafe, but there are still
> a number of considerations that come from sharing memory. In particular, you
> must ensure that no signal handlers run in the child while it's sharing
> memory with the parent, and the parent must be responsible for freeing the
> child's stack, and thus must synchronize with the execve call in the child.
> 
> I have a working implementation in musl which solves these problems (it uses
> clone with CLONE_VM for all posix_spawn operations) if anyone is interested
> in looking at it and doing something similar for glibc.

I agree this issue should be fixed.

posix_spawn() could use vfork() in many more cases than it does today, and
cancellation is no excuse not to fix this. I agree that cancellation in the
context of the child doesn't make any sense. The child needs to just not touch
the cancel state, and with signals blocked it will never act on a SIGCANCEL
request anyway.

We can perhaps revisit this after we fix cancellation to work correctly.

-- 
You are receiving this mail because:
You are on the CC list for the bug.