> Actually, you only need the parent to get the status from the child,
which can be passed in other way than through common memory.
Certainly, it *can* be, but the glibc code we're trying to run in the
guest here doesn't do it in some other way, it uses common memory.
Having QEMU effectively
Hello
Sorry for the delay...
Actually, you only need the parent to get the status from the child,
which can be passed in other way than through common memory.
The idea is to use pipefd to actually wait for the child to either
terminate or successfully call execve. As follow:
When the
That way round the child doesn't have the shared memory with the parent,
so it can't update the parent's status variable. There's no easy way to
say "fork, and then share the guest memory mappings and only the guest
memory mappings with the child", because QEMU doesn't currently track
what memory
Ok, I taught that could be an issue, but as I said, I don't really know
all the internals of QEMU.
Another idea would be to fork the child, without CLONE_VM, on the
initial call to the clone syscall, like it's done right now, and then
wait for that child until he call execve or exit syscall.
Unfortunately that won't work, because if we do a clone(CLONE_VM) in
QEMU that will mean that parent and child share not just the guest
address space, but also all the QEMU data structures for the emulated
CPUs and also the host libc data structures. Then actions done by the
child will update
Ok, yes you are right...
I have looked a bit more on the source code, and indeed, I think
understand the issue with the VFORK with QEMU. Please correct me if I'm
wrong...
- In the syscall trap handler, it has to use the fork() function to emulate the
vfork() due to restriction of the vfork()
Commit fe05e1cb6d64db changed that, so args.err is initialized to zero.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1673976
Title:
linux-user clone() can't handle glibc posix_spawn() (causes
Ok, thank you for clearing that up.
I'm noticing in 4b4d4056bb154 this comment:
"...we just make explicit use of the fact the the child and parent run
in the same VM, so the child can write an error code to a field of the
posix_spawn_args struct instead of sending it through a pipe. To ensure
That glibc change has caused the assert to go away, but QEMU's
spawn(CLONE_VFORK) still does not have the "always waits for child"
semantics that glibc has assumed since glibc commit 4b4d4056bb154. The
child and the parent will end up racing each other, and the child will
never be able to write to
This should probably be put under 'glibc', since this is really an issue
with that package, which is fixed by the way since Oct 2017.
https://sourceware.org/git/?p=glibc.git;a=commit;h=fe05e1cb6d64dba6172249c79526f1e9af8f2bfd
This should also be backported to 17.10
--
You received this bug
I have verified that this patch [1] in glibc_2.25 and glibc_2.26 fixes
the assert.
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=22273
** Bug watch added: Sourceware.org Bugzilla #22273
https://sourceware.org/bugzilla/show_bug.cgi?id=22273
--
You received this bug notification
Interestingly, this also affects Microsoft Windows Services For Linux,
i.e. Microsoft's Linux emulation layer.
> https://github.com/Microsoft/WSL/issues/1878
** Bug watch added: github.com/Microsoft/WSL/issues #1878
https://github.com/Microsoft/WSL/issues/1878
--
You received this bug
Thanks for tracking down the glibc change; I will try to set up a chroot
with a more recent glibc to see whether we can do something that fixes
that posix_spawn implementation...
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
I think I see the problem. This glibc commit rewrote the posix_spawn
implementation on Linux:
https://sourceware.org/git/?p=glibc.git;a=commit;h=9ff72da471a509a8c19791efe469f47fa6977410
It now relies on the exact behavior of clone(CLONE_VM | CLONE_VFORK) - ie:
- That the parent will wait for the
Sorry, this is probably the commit that broke things (not the one above). I was
added in glibc 2.25:
https://sourceware.org/git/?p=glibc.git;a=commit;h=4b4d4056bb154603f36c6f8845757c1012758158
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed
I can reproduce the bug in a mips64el chroot running current Debian
unstable - the posix_spawn example you mention fails there. I have
tested v2.11.0-rc2 and it fails there as well. I think you need glibc >=
2.25 to trigger the bug (artful / bionic chroot). I only noticed it due
to Debian updating
OK, this can't be as simple as "posix_spawn() fails", because I've just
tried the test program from the posix_spawn manpage
(http://man7.org/linux/man-pages/man3/posix_spawn.3.html) and that works
fine for x86-64 guest, aarch64 guest and armhf guest. In the x86 and
armhf cases the libc I have
Not without messing with the QEMU source, no.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1673976
Title:
linux-user clone() can't handle glibc posix_spawn() (causes locale-gen
to assert)
Is there a way I can ask QEMU to not do this strict checking so that my
stuff stops breaking?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1673976
Title:
linux-user clone() can't handle glibc
19 matches
Mail list logo
