On 27 November 2017 at 12:57, Adhemerval Zanella <adhemerval.zane...@linaro.org> wrote: > We found out this potential bogus assert on 2.27 development [1] which > resulted in two fixes [2][3]. > > It should not be an issue for generic posix_spawn usage where there is > no expectation system/user/program kills random pids (since posix_spawn > auxiliary process has not yet returned). Some say the possible kind of > behaviour is rather undefined, but it shouldn't also trigger an assert. > > I am not really sure what is happening in qemu usermode because comment > #4 in the bug reports states clone is returning an error and it should > not trigger the assert in first place. What seems to be happening in > this scenario is clone is actually returning a success, but the auxiliary > process is being killed before actually calling execve.
The bug report is a bit confused, but I think what is happening in the QEMU case is that QEMU implements clone(CLONE_VFORK) as having the same semantics as fork() (ie the parent will not autowait for the child, and the child does not share a memory map with the parent). (ie QEMU treats it as having the semantics of a vfork() call, which is allowed to be implemented as fork()). Previous versions of glibc's posix_spawn() could cope with this divergence from the kernel's native clone() behaviour, but the rewrite can't. It's not unreasonable for glibc() to rely on the kernel behaviour, but on the other hand it's not too surprising if this breaks non-kernel implementations of the syscall ABI like QEMU and the MS Linux subsystem, because it's a tricky corner case that previously nobody was trying to use. Unfortunately I can't really think of a mechanism for implementing this in QEMU usermode, because the only tools we have available for creating new threads and processes are the ones the host libc gives us: so we can spawn new threads with pthread_create() and fork the process with fork(), but we don't have a safe way to create a new process which shares the memory map and where the new process can call the various libc functions which QEMU will do as it executes the guest code. thanks -- PMM