<div dir="ltr"><div>Hi,</div><div><br></div><div>I am currently working on child process issues and again noticed how inherently dangerous the vfork mode is. </div><div><br></div><div>The child process can damage or kill the parent process if bad things happen in the time window between vfork and exec, when we prepare the target binary execution. For a non-exclusive list of things that can go wrong please see my old mail from 2018 here:</div><div><br></div><div><a href="https://mail.openjdk.org/pipermail/core-libs-dev/2018-September/055333.html">https://mail.openjdk.org/pipermail/core-libs-dev/2018-September/055333.html</a></div><div><br></div><div>These errors are vicious too, since they would rarely be attributable to vfork; they would probably look like random crashes or libc problems.</div><div><br></div><div>Back in 2018, I proposed an exec-twice technique whereby one execs a helper binary first to isolate the child process preparations; then do the final exec of the target binary. That is safe, fast, and it works. We can still do this. Would be wven simpler to implement now: we have the jspawnhelper and can just reuse that for vfork.</div><div><br></div><div>However,  we also could just get rid of vfork. That would simplify things alot. We have moved to posix_spawn-by-default with JDK 13 in 2019 (<a href="https://bugs.openjdk.org/browse/JDK-8213192">https://bugs.openjdk.org/browse/JDK-8213192</a>). That is a long time ago; probably long enough to ween all customers off vfork use.</div><div><br></div><div>What do people think?</div><div><br></div><div>Thanks, Thomas</div><div><br></div><div><br></div></div>