Am 04.08.2015 um 14:09 schrieb Paolo Bonzini:
On 04/08/2015 13:57, Peter Lieven wrote:
Okay, what I found out is that in aio_poll I get revents = POLLIN for
the nfs file descriptor. But there is no data available on the socket.
Does read return 0 or EAGAIN?
If it returns EAGAIN, the bug is in the QEMU main loop or the kernel.
It should never happen that poll returns POLLIN and read returns EAGAIN.
If it returns 0, it means the other side called shutdown(fd, SHUT_WR).
Then I think the bug is in the libnfs driver or more likely libnfs. You
should stop polling the POLLIN event after read has returned 0 once.
You might be right. Ronnie originally used the FIONREAD ioctl before every read
and considered
the socket as disconnected if the available bytes returned where 0.
I found that I get available bytes == 0 from that ioctl even if the socket was
not closed.
This seems to be some kind of bug in Linux - at least what I have thought.
See BUGS in the select(2) manpage.
Under Linux, select() may report a socket file descriptor as "ready for
reading", while nevertheless a subsequent read blocks. This could for example happen
when data has arrived but
upon examination has wrong checksum and is discarded. There may be
other circumstances in which a file descriptor is spuriously reported as ready.
Thus it may be safer to use O_NON‐
BLOCK on sockets that should not block.
I will debug further, but it seems to be that I receive a POLLIN even if there
is no data available. I see 0 bytes from the recv call inside libnfs and
continue without a deadlock - at least
so far.
Would it be a good idea to count the number of 0 bytes from recv and react
after I received 0 bytes for a number of consecutive times?
And then: stop polling POLLIN or reconnect?