All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amit Shah <amit.shah@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
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>
Subject: Re: PATCH: virtio_console: Fix poll blocking even though there is data to read
Date: Thu, 16 Sep 2010 11:52:01 +0530	[thread overview]
Message-ID: <20100916062201.GC2429@amit-laptop.redhat.com> (raw)
In-Reply-To: <201009161532.55462.rusty@rustcorp.com.au>

On (Thu) Sep 16 2010 [15:32:54], Rusty Russell wrote:
> 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 = 0;
> > > >>-	if (port->inbuf)
> > > >>+	if (!will_read_block(port))
> > > >
> > > >Looks correct, but this should be
> > > >
> > > >	if (port_has_data(port))
> > > >
> > > >instead.
> > > 
> > > That certainly works for me (as in will still fix the bug I'm hitting), but
> > > quoting from "man 2 select":
> > > 
> > >        Three  independent  sets of file descriptors are watched.  Those listed
> > >        in readfds will be watched to see if characters  become  available  for
> > >        reading  (more  precisely, to see if a read will not block; in particu‐
> > >        lar, a file descriptor is also ready on end-of-file)
> > > 
> > > 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 returns 0
> > > in that case). So from an API pov I'm not sure what is correct.
> > 
> > poll(2) says:
> > 
> >               POLLIN There is data to read.
> > 
> > That makes it simple.
> 
> That's a documentation bug.  On a pipe, POLLIN is set when the other end
> closes.  read() then returns 0 immediately.

Currently we don't set POLLIN when host goes down.  I'll do a second
patch for that.

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

Yes, that's the behaviour with Hans's new patch as well -- that's not
changing.

The will_read_block() function (and the comment on top of it) are
causing this confusion:


/* The condition that must be true for polling to end */
static bool will_read_block(struct port *port)
{
	if (!port->guest_connected) {
		/* Port got hot-unplugged. Let's exit. */
		return false;
	}
	return !port_has_data(port) && port->host_connected;
}

This function is only called to unblock a blocking read() call.  So the
comment there has to be changed to read 'waiting' to end instead of
'polling' to end.

read() does return 0 immediately when the other end is not connected
(and there's no data to read).

In effect, we need:
- Hans's patch
- a patch to set POLLIN when host goes down (in addition to POLLHUP and
  SIGIO)
- a patch to change the comment for will_read_block.

Thanks,

		Amit

  parent reply	other threads:[~2010-09-16  6:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-15 13:04 PATCH: virtio_console: Fix poll blocking even though there is data to read Hans de Goede
2010-09-15 13:25 ` Amit Shah
2010-09-15 13:37   ` Hans de Goede
2010-09-15 13:37   ` Hans de Goede
2010-09-15 13:46     ` Amit Shah
2010-09-15 13:46     ` Amit Shah
2010-09-15 14:02       ` Hans de Goede
2010-09-15 14:02       ` Hans de Goede
2010-09-16  6:02       ` Rusty Russell
2010-09-16  6:02       ` Rusty Russell
2010-09-16  6:22         ` Amit Shah
2010-09-16  6:22         ` Amit Shah [this message]
2010-09-16  7:16           ` Amit Shah
2010-09-16  7:16           ` Amit Shah
2010-09-15 13:25 ` Amit Shah
  -- strict thread matches above, loose matches on Subject: below --
2010-09-15 13:04 Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100916062201.GC2429@amit-laptop.redhat.com \
    --to=amit.shah@redhat.com \
    --cc=hdegoede@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtk.manpages@googlemail.com \
    --cc=rusty@rustcorp.com.au \
    --cc=spice-devel@lists.freedesktop.org \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.