From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:58840)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1ZMuF8-00050d-Qb
	for qemu-devel@nongnu.org; Wed, 05 Aug 2015 04:40:14 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1ZMuF6-0001h6-0X
	for qemu-devel@nongnu.org; Wed, 05 Aug 2015 04:40:10 -0400
Sender: Paolo Bonzini <paolo.bonzini@gmail.com>
References: <55BB2DF7.8010808@kamp.de> <55BB302D.50108@redhat.com>
	<55BB335A.1010009@kamp.de> <55BB3FE7.3000106@redhat.com>
	<55C08461.1040308@kamp.de> <55C0A7AA.70609@redhat.com>
	<55C0A88D.1010800@kamp.de> <55C0AB81.8020404@redhat.com>
	<55C0B03D.8000109@kamp.de> <55C0B5B9.4040001@kamp.de>
	<CAN05THSN09B94JZ9DQ1AV6JKKmNhjKZ9mEHoExodfQ-grukK5w@mail.gmail.com>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <55C1CBDA.6050803@redhat.com>
Date: Wed, 5 Aug 2015 10:39:54 +0200
MIME-Version: 1.0
In-Reply-To: <CAN05THSN09B94JZ9DQ1AV6JKKmNhjKZ9mEHoExodfQ-grukK5w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [Qemu-stable] Recent patches for 2.4
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: ronnie sahlberg <ronniesahlberg@gmail.com>, Peter Lieven <pl@kamp.de>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Stefan Hajnoczi <stefanha@redhat.com>, qemu-stable@nongnu.org



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.

Paolo

> I verified this by adding an extra call to poll() at around line 78
> to check whether POLLIN was actually set on the fd or not. Sometimes it
> would not be but I got lost in the sources and could not find if or
> where this happens or even if qemu even guarantees "only call the POLLIN
> callbacks if the filedescriptor is actually readable".
>