[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libguestfs] [nbdkit PATCH 8/8] rate: Atomically set CLOEXEC on fds

On 7/31/19 4:31 PM, Eric Blake wrote:
> The rate filter is potentially opening fds in one thread while another
> thread is processing a fork() in the plugin.  Although the file is not
> open for long, we MUST atomically use CLOEXEC to avoid fd leaks.  This
> one is a bit harder to observe using only the sh plugin, because the
> window is small; you'll have better success at catching the leak by
> using gdb or recompiling code to insert strategic sleeps.

In fact, I have to tweak this commit message: you CAN'T observe this one
with the sh plugin unless you recompile it to use #define THREAD_MODEL
timing hacks mentioned above (that's because with our current
SERIALIZE_ALL_REQUESTS, there is never more than one thread in
filter/plugin code at a time).

But it does raise an interesting point - if we hit platforms that are
unable to support atomic CLOEXEC, one possibility is a patch that forces
SERIALIZE_ALL_REQUESTS as the maximum parallelism allowed on that
platform (while remaining at our goal of PARALLEL on more competent
systems) - once we do that, the lacking systems will be serialized to
the point that there is no race window where one thread can fork() while
another is obtaining an fd.

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

Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]