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

[Peter Lieven]

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