* Eric Blake: > Does anyone know if glibc guarantees that opendir/readdir in between > multi-threaded fork() and exec() is safe, even though POSIX does not > guarantee that safety in general? glibc supports malloc after multi-threaded fork as an extension (or as a bug, because it makes malloc not async-signal-safe). Lots of programs depend on this. OpenJDK even calls malloc after vfork, which is not officially supported (but of course we can't break OpenJDK). > I know that one approach to avoid > having to close all fds is religiously using O_CLOEXEC everywhere (so > that the race window of having an fd that would leak is not possible), > but that's also an expensive audit, compared to just ensuring that > things are closed after fork(). Are there any other ideas out there > that we should be aware of (and no, pthread_atfork is not a sane idea)? > (various BSD systems have the closefrom() syscall which is more > efficient than lots of close() calls; and Linux may be adding something > similar https://lwn.net/Articles/789023/), Is there any saner way to > close all unneeded fds that were not properly marked O_CLOEXEC by an > application linking against a multithreaded lib that must perform fork/exec? I tried to add getdents64 (which got committed, but may yet move from <unistd.h> to <dirent.h>, to match musl) and <sys/direntries.h> (which did not) in glibc 2.30. Those interfaces are async-signal-safe (except on some MIPS variants, where getdents64 has complex emulation). If you do not want to use opendir/readdir, issuing getdents64 directly and parsing the buffer is your best option right now. (Lowering the RLIMIT_NOFILE limit does not enable probing for stray descriptors, unfortunately.) But opendir/readdir after fork should be fine, really. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
