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. 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. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
