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