* Linus Torvalds: > On Mon, Apr 29, 2019 at 1:38 PM Florian Weimer <fwei...@redhat.com> wrote: >> >> In Linux-as-the-ABI (as opposed to Linux-as-the-implementation), vfork >> is sometimes implemented as fork, so applications cannot rely on the >> vfork behavior regarding the stopped parent and the shared address >> space. > > What broken library does that? > > Sure, we didn't have a proper vfork() long long long ago. But that > predates both git and BK, so it's some time in the 90's. We've had a > proper vfork() *forever*.
It's not so much about libraries, it's alternative implementations of the system call interface: valgrind, qemu-user and WSL. For valgrind and qemu-user, it's about cloning the internal data structures, so that the subprocess does not clobber what's in the parent process (which may have multiple threads and may not be fully blocked due to vfork). For WSL, who knows what's going on there. >> In fact, it would be nice to have a flag we can check in the posix_spawn >> implementation, so that we can support vfork-as-fork without any run >> time cost to native Linux. > > No. Just make a bug-report to whatever broken library you use. What's > the point of having a library that can't even get vfork() right? Why > would you want to have a flag to say "vfork is broken"? It's apparently quite difficult to fix valgrind and qemu-user. WSL is apparently not given the resources it needs, yet a surprising number of people see it as a viable replacement and report what are essentially vfork-related bugs. If I had the flag, I could at least fix posix_spawn in glibc to consult it before assuming that vfork shares address space. (The sharing allows straightforward reporting of the vfork error code, without resorting to pipes or creating a MAP_SHARED mapping.) For obvious reasons, I do not want to apply the workaround unconditionally. Thanks, Florian
