Re: [Qemu-devel] [Qemu-stable] Recent patches for 2.4

[Peter Lieven <pl@kamp.de>]

Am 05.08.2015 um 10:39 schrieb Paolo Bonzini:
>
> On 05/08/2015 01:23, ronnie sahlberg wrote:
>> You only get >0 from this call if there are actual bytes available to read.
>>
>> For context,  the problem was that
>>
>>
>>    75 static void nfs_process_read(void *arg)
>>    76 {
>>    77     NFSClient *client = arg;
>>    78     nfs_service(client->context, POLLIN);
>>    79     nfs_set_events(client);
>>    80 }
>>
>> sometimes trigger and call nfs_service(POLLIN) eventhough the socket is
>> not readable.
> Does read() return -1/EAGAIN or 0?
>
> If it returns 0, then this is expected: it means that the other side has
> shutdown the socket's write-side.  libnfs should either reconnect, or
> disable POLLIN, treat all pending operations as aborted and stop
> submitting more.

I also went on reproducing and can confirm, that I see FIONREAD return
0 bytes available when booting a CDROM in Qemu with libnfs before commit
cf420d3 (socket: use FIONREAD ioctl only for UDP). But a lot has changed
in rpc_read_from_socket in libnfs since we dropped FIONREAD. Most importantly
we changed from recv without flags to recv with MSG_DONTWAIT. And with
current master I never receive spurious readiness any more. So there is
nothing we need to fix here except from handling recv return 0 bytes and
then reconnect. This fix is already in the current master of libnfs. And this
solves the deadlock in qemu-img I have observed.

Thanks for you help,
Peter