On 07/11/2016 23:45, Eric Blake wrote: > On 11/07/2016 04:22 PM, Max Reitz wrote: >> On 07.11.2016 21:38, Eric Blake wrote: >>> Commit 7d3123e converted a single read_sync() into a while loop >>> that assumed that read_sync() would either make progress or give >>> an error. But when the server hangs up early, the client sees >>> EOF (a read_sync() of 0) and never makes progress, which in turn >>> caused qemu-iotest './check -nbd 83' to go into an infinite loop. >>> >>> Rework the loop to accomodate reads cut short by EOF. >>> >>> Reported-by: Max Reitz <mre...@redhat.com> >>> Signed-off-by: Eric Blake <ebl...@redhat.com> >>> --- >>> nbd/client.c | 13 +++++++------ >>> 1 file changed, 7 insertions(+), 6 deletions(-) >> >> Reviewed-by: Max Reitz <mre...@redhat.com> >> >> But what about the server's nbd_negotiate_drop_sync()? It uses pretty >> much the same code, so it seems susceptible to the same issue (only that >> we don't have a test for that side). > > If so, that's an older bug (pre-existing back to at least 2.6?), so it > should be a separate fix, if anything. > > I guess it's time to figure out how to test the server against > ill-behaved clients...
Using afl perhaps? Paolo
