On Sun, Jul 14, 2019 at 07:23:10AM +0200, Florian Weimer wrote: > * 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). Yep, libvirt already relies glibc semantics that let malloc/free work after fork(), for other code we've had since essentially forever. > > 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. Ok, lets just keep it simple & use opendif/readdir. If we ever hit problems, we can just disable the code & go back to the slower code we have right now. Hopefully the kernel folks will finally merge one of the recent closefrom()-like proposals and make life much easier. 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
