This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: [libvirt] [PATCH 3/3] virCommand: use procfs to learn opened FDs
- From: Daniel P. Berrangé <berrange at redhat dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: Eric Blake <eblake at redhat dot com>, libvir-list at redhat dot com, Michal Prívozník <mprivozn at redhat dot com>, libc-help at sourceware dot org
- Date: Mon, 15 Jul 2019 15:35:15 +0100
- Subject: Re: [libvirt] [PATCH 3/3] virCommand: use procfs to learn opened FDs
- References: <cover.1562138162.git.mprivozn@redhat.com> <8cf311e297b18b159d3bb6dc201df260585b904c.1562138162.git.mprivozn@redhat.com> <0f316f41-225a-23b4-e923-46edef6576dc@redhat.com> <72d0d244-0d7f-3015-056e-c86298d37974@redhat.com> <7b2ada48-1d2a-98fa-d954-c2685b0e4059@redhat.com> <87blxx6vgh.fsf@mid.deneb.enyo.de>
- Reply-to: Daniel P. Berrangé <berrange at redhat dot com>
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 :|