On 7/2/19 9:01 AM, Eric Blake wrote:
> This test fails when run under valgrind. An abbreviated log
shows
> what's happening:
>
> I wonder if we could remove the race using a custom
nbdkit-sh-plugin
> which would block on writes until (eg) a local trigger file was
> touched? Even that seems as if it would depend on the amount of data
> that the kernel is able to buffer.
I don't know how to make an nbdkit plugin stop the code in nbdkit/server
from read()ing from the client (the plugin code doesn't get to run until
the core has learned that the client wants a command serviced). But it
may be possible to tweak things to send back-to-back write requests,
where even if the first write request gets sent completely, the plugin
can delay responding to that first write and use --filter=noparallel to
prevent the second command from reaching nbdkit. I'll play with that,
to see if I can reproduce the valgrind race, as well as work around it
with back-to-back write commands to increase the likelihood of actually
preventing nbdkit from consuming the second command.
Should be fixed now.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org