On Tue, 18 Mar 2025 at 17:18, Daniel P. Berrangé <berra...@redhat.com> wrote: > > On Tue, Mar 18, 2025 at 05:08:52PM +0000, Peter Maydell wrote: > > On Tue, 18 Mar 2025 at 15:04, Peter Maydell <peter.mayd...@linaro.org> > > wrote: > > > More generally, AIUI glibc expects that it has control over what's > > > happening with threads, so it can set up its own data structures > > > for the new thread (e.g. for TLS variables). This email from the > > > glibc mailing list is admittedly now two decades old > > > https://public-inbox.org/libc-alpha/200408042007.i74k7zor025...@magilla.sf.frob.com/ > > > but it says: > > > > > > # Basically, if you want to call libc functions you should do it from a > > > # thread that was set up by libc or libpthread. i.e., if you make your > > > own > > > # threads with clone, only call libc functions from the initial thread. > > > > I spoke to some glibc devs on IRC and they confirmed that this > > remains true for modern glibc: because glibc needs to set up > > things like TLS on new threads, you can't mix your own direct > > calls to clone() with calls to glibc functions. > > Using clone() directly is done by a number of projects (systemd, libvirt, > podman/docker/runc, etc) that want to create containers, while freely using > arbitrary glibc calls in the program. You do need to be careful what glibc > functions you run in the child after clone, but before execve though.
Yes, if you don't call glibc functions in the child that's fine. If those other projects are calling some glibc functions post clone() in the child then I think they're relying on undocumented behaviour that might break on them in future... > For the projects I mention, avoiding the danger areas is probably easier > than for QEMU, since QEMU has to theoretically cope with whatever madness > the guest program chooses to do, while those programs know exactly what > they will run between clone & execve. QEMU's structure also is that we assume we can freely call glibc functions as a result of TCG operations. So even if the child in the guest is very carefully doing absolutely no other library calls between clone and execve, QEMU itself will be doing them. > Wonder if its worth enquiring if glibc would be interested > in following musl's approach to make it more emulation friendly for > QEMU ? That would essentially be asking "please can you revert glibc commit 4b4d4056bb154603f36 ?", so probably not: https://sourceware.org/git/?p=glibc.git;a=commit;h=4b4d4056bb154603f36 -- PMM
