From mboxrd@z Thu Jan  1 00:00:00 1970
From: Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: PATCH: virtio_console: Fix poll blocking even though there is data to read
Date: Thu, 16 Sep 2010 15:32:54 +0930
Message-ID: <201009161532.55462.rusty@rustcorp.com.au>
References: <4C90C475.4010809@redhat.com> <4C90CC11.70202@redhat.com> <20100915134624.GB12320@amit-laptop.redhat.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Hans de Goede <hdegoede@redhat.com>,
	virtualization@lists.linux-foundation.org, kvm@vger.kernel.org,
	spice-devel@lists.freedesktop.org,
	"Michael Kerrisk" <mtk.manpages@googlemail.com>
To: Amit Shah <amit.shah@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from ozlabs.org ([203.10.76.45]:52604 "EHLO ozlabs.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752188Ab0IPGDC convert rfc822-to-8bit (ORCPT
	<rfc822;kvm@vger.kernel.org>); Thu, 16 Sep 2010 02:03:02 -0400
In-Reply-To: <20100915134624.GB12320@amit-laptop.redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Wed, 15 Sep 2010 11:16:24 pm Amit Shah wrote:
> On (Wed) Sep 15 2010 [15:37:21], Hans de Goede wrote:
> > >>--- linux-2.6.35.x86_64/drivers/char/virtio_console.c~	2010-08-02=
 00:11:14.000000000 +0200
> > >>+++ linux-2.6.35.x86_64/drivers/char/virtio_console.c	2010-09-15 =
13:39:29.043505000 +0200
> > >>@@ -642,7 +642,7 @@ static unsigned int port_fops_poll(struc
> > >>  	poll_wait(filp,&port->waitqueue, wait);
> > >>
> > >>  	ret =3D 0;
> > >>-	if (port->inbuf)
> > >>+	if (!will_read_block(port))
> > >
> > >Looks correct, but this should be
> > >
> > >	if (port_has_data(port))
> > >
> > >instead.
> >=20
> > That certainly works for me (as in will still fix the bug I'm hitti=
ng), but
> > quoting from "man 2 select":
> >=20
> >        Three  independent  sets of file descriptors are watched.  T=
hose listed
> >        in readfds will be watched to see if characters  become  ava=
ilable  for
> >        reading  (more  precisely, to see if a read will not block; =
in particu=E2=80=90
> >        lar, a file descriptor is also ready on end-of-file)
> >=20
> > Notice the "a file descriptor is also ready on end-of-file", and
> > port_fops_read treats the host not being connected as eof (it retur=
ns 0
> > in that case). So from an API pov I'm not sure what is correct.
>=20
> poll(2) says:
>=20
>               POLLIN There is data to read.
>=20
> That makes it simple.

That's a documentation bug.  On a pipe, POLLIN is set when the other en=
d
closes.  read() then returns 0 immediately.

poll() sets POLLIN when read() won't block, and people count on it.

Let's do that, please.
Rusty.