[Libguestfs] [libnbd PATCH 3/6] macOS: Simple cloexec/nonblock fix

Eric Blake eblake at redhat.com
Tue Jul 20 18:27:38 UTC 2021


On Sat, Jul 17, 2021 at 04:10:14PM +0100, Richard W.M. Jones wrote:
> > Is the fuzzer multithreaded?  Or can we just blindly do the workaround
> > ourselves and not worry about trying to use SOCK_CLOEXEC here?  Also, it feels like some duplication; can we not reuse nbd_internal_socketpair from the fuzzer?
> 
> AFL-type fuzzers which all use libnbd-fuzz-wrapper.c are not
> multithreaded.  They will launch a new process for each test case.  I
> don't think they could easily be multithreaded: part of the goal is to
> try to make the test program crash, and they also require
> instrumenting the test binary.
> 
> As an aside our test case / wrapper also creates a subprocess since it
> creates a phony NBD server (the child), connects the two processes by
> a socketpair, and runs libnbd in the parent.  (Now that I look again
> at the code this might be changed to use two threads instead of
> processes, not that it would make much difference on Linux.)
> 
> Since the test case never calls exec it doesn't seem to me that we
> need to set SOCK_CLOEXEC at all, it's just a code cleanliness thing.

Ah, so the simplest solution might be:

#ifndef SOCK_CLOEXEC
#define SOCK_CLOEXEC 0 /* This file doesn't use exec */
#endif

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




More information about the Libguestfs mailing list