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
