Re: [Qemu-devel] glibc "linux: spawni.c: simplify error reporting to parent" breaks qemu-user/Windows Service For Linux

[Peter Maydell]

On 27 November 2017 at 12:57, Adhemerval Zanella
<address@hidden> 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