On 06/07/2017 12:55 AM, Michal Privoznik wrote:
On 06/06/2017 07:24 PM, Jim Fehlig wrote:
On 06/05/2017 06:53 AM, Michal Privoznik wrote:
There's a problem with current streams after I switched them from
iohelper to thread implementation. Previously, iohelper made sure
not to exceed specified @length resulting in the pipe EOF
appearing at the exact right moment (the pipe was used to tunnel
the data from the iohelper to the daemon). Anyway, when switching
to thread I had to write the I/O code from scratch. Whilst doing
that I took an inspiration from the iohelper code, but since the
usage of pipe switched to slightly different meaning, there was
no 1:1 relationship between the codes.
Moreover, after introducing VIR_FDSTREAM_MSG_TYPE_HOLE, the
condition that should made sure we won't exceed @length was
completely wrong.
The fix is to:
a) account for holes for @length
b) cap not just data sections but holes too (if @length would be
exceeded)
For this purpose, the condition needs to be brought closer to the
code that handles holes and data sections.
For the record, this fixes the libvirt-tck failures I mentioned. Thanks!
I think this made it harder to hit the hang.
Indeed. Looping through the tests 25 times produced no failures. Before this
patch, roughly 2/3 of those would fail.
The proper fix should be this one (still unreviewed ;-)):
https://www.redhat.com/archives/libvir-list/2017-June/msg00280.html
Thanks for the pointer. I reviewed it.
Regards,
Jim
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
