[Libguestfs] [nbdkit PATCH 4/8] Revert "RHEL 5: Define O_CLOEXEC and SOCK_CLOEXEC."

[Eric Blake]

On 8/1/19 5:06 AM, Eric Blake wrote:
> On 8/1/19 4:15 AM, Richard W.M. Jones wrote:
>> On Thu, Aug 01, 2019 at 10:06:01AM +0100, Richard W.M. Jones wrote:
>>> As far as I can see Haiku (hrev52698) has O_CLOEXEC but NOT
>>> SOCK_CLOEXEC.  As this version is a little old I'll do an update and
>>> see if newer versions support it.
>>
>> I'm on hrev53313+1 which also doesn't appear to have SOCK_CLOEXEC (nor
>> does it have accept4).
> 
> Ouch. Then I'm seriously thinking of a followup patch which either
> forces SERIALIZE_ALL_REQUESTS on all plugins when SOCK_CLOEXEC is
> missing, or which adds a bool to the plugin interface that the plugin
> sets to true if it does not fork (default to false), and where we force
> SERIALIZE_ALL_REQUESTS plugins which have not set it to true (most of
> our in-tree plugins can set the bool to true).

In fact, this is probably still worthwhile, but I could possibly go one
step further - you can ALSO set the bool that you are fork-safe if, in
between fork and exec, you close all fds that happened to be leaked
(that benefits from something like BSD's closefrom() for bulk-closing,
or from glibc's ability to do opendir("/proc/self/fd") after fork in
spite of POSIX stating that because opendir is not required to be
async-signal-safe you could deadlock on other platforms).  We do NOT
want nbdkit to do the close-all-fds dance in general, only on platforms
where we don't have atomic CLOEXEC (because nbdkit is the main program,
we should have absolute control over all fds created).  Note that the
stance in libvirt is opposite: because that is a library, and may be
linked in with a 3rd-party main executable that did not religiously use
atomic CLOEXEC, libvirt has no choice but to do the close-all-fds dance
on every fork.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190801/84fd8a7f/attachment.sig>