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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
