Re: [libvirt] [PATCH 3/3] virCommand: use procfs to learn opened FDs
On 7/14/19 12:23 AM, 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).
It's not a bug for glibc to provide guarantees above what POSIX
requires, but IS a bug for applications to depend on those guarantees
without realizing they are non-portable.
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.
Thanks for checking; I'm okay with the patch that started this thread
going in libvirt if we tweak it to also include a big fat comment
stating that use of opendir/readdir is not safe in general, but should
be safe in this specific use (because glibc adds async-signal safety to
those functions that was not required by POSIX), since the patch is only
using opendir on Linux.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 488 bytes)