[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