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