[Bug nptl/17214] Expose a clone variant that shares stacks instead of jumping to a new one

["bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #14 from Rich Felker <bugdal at aerifal dot cx> ---
Your claim that "vfork sets all memory except the current stack as read only in
the process" is false and generally impossible to implement for various
reasons. At the kernel level vfork is identical to clone with
flags=CLONE_VM|CLONE_VFORK|SIGCHLD, and all CLONE_VFORK does is block
scheduling of the parent until the child successfully execs or terminates.

By "eliminated", I meant dropped from the standards and deprecated. Of course
it still exists in implementations that provide it, but the formalism for what
you can do after vfork is wrong with respect to compiler semantics and thus
it's unusable. For instance in the code:

if (!(pid = vfork())) {
    execve(...);
    _exit(1);
}

the traditional rules have been followed, but since _exit is a _Noreturn
function, the compiler is free to write the arguments for execve over top of
storage that was being used for local variables or spilled/saved registers in
the caller (assuming their addresses are not visible to execve). This is valid
because they can never be accessed again in the child. But since the child and
parent share memory, the parent's stack will be trashed when it resumes
execution. There are hacks that could be done at the compiler level to
recognize vfork as special and avoid this, but it's a game of whack-a-mole.
Sharing a stack between processes is just a broken design.

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