From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amit Shah Subject: Re: [PATCH 06/10] virtio: console: fix race in port_fops_poll() and port unplug Date: Tue, 23 Jul 2013 13:38:14 +0530 Message-ID: <20130723080814.GA25551@amit-x200.redhat.com> References: <51E8E4D6.7030807@redhat.com> <20130719072113.GL3087@amit-x200.redhat.com> <51E9123C.5040708@redhat.com> <20130719102941.GN3087@amit-x200.redhat.com> <87fvv7b11d.fsf@rustcorp.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <87fvv7b11d.fsf@rustcorp.com.au> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Rusty Russell Cc: Virtualization List List-Id: virtualization@lists.linuxfoundation.org On (Mon) 22 Jul 2013 [15:15:34], Rusty Russell wrote: > Amit Shah writes: > > On (Fri) 19 Jul 2013 [18:17:32], Jason Wang wrote: > >> On 07/19/2013 03:48 PM, Amit Shah wrote: > >> > On (Fri) 19 Jul 2013 [15:03:50], Jason Wang wrote: > >> >> On 07/19/2013 04:16 AM, Amit Shah wrote: > >> >>> Between poll() being called and processed, the port can be unplugged. > >> >>> Check if this happened, and bail out. > >> >>> > >> >>> Signed-off-by: Amit Shah > >> >>> --- > >> >>> drivers/char/virtio_console.c | 4 ++++ > >> >>> 1 file changed, 4 insertions(+) > >> >>> > >> >>> diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c > >> >>> index 7728af9..1d4b748 100644 > >> >>> --- a/drivers/char/virtio_console.c > >> >>> +++ b/drivers/char/virtio_console.c > >> >>> @@ -967,6 +967,10 @@ static unsigned int port_fops_poll(struct file *filp, poll_table *wait) > >> >>> unsigned int ret; > >> >>> > >> >>> port = filp->private_data; > >> >>> + if (!port->guest_connected) { > >> >>> + /* Port was unplugged before we could proceed */ > >> >>> + return POLLHUP; > >> >>> + } > >> >>> poll_wait(filp, &port->waitqueue, wait); > >> >>> > >> >>> if (!port->guest_connected) { > >> >> Looks still racy here. Unlike port_fops_read() which check > >> >> will_read_block(). If unplug happens after the check but before the > >> >> poll_wait(), caller will be blocked forever. > >> > unplug_port() calls wake_up_interruptible on the waitqueue. > >> > >> I mean the following cases: > > > > (formatting to fit properly:) > > > >> > >> CPU0: CPU1: unplug_port() > >> > >> if (!port->guest_connected) { > >> return POLLHUP; > >> } > >> wake_up_interruptiable() > >> > >> poll_wait(filp, &port->waitqueue, wait); > > > > Agreed, this can happen. I can't think of a way to resolve this. One > > way would be to remove the waitqueue (port->waitqueue = NULL in > > unplug_port()), but I'm not sure of the effect on the other parts > > yet. I'll leave this one for later analysis. > > No, you are confused by the name, I think, > > poll_wait() doesn't actually wait. It's more like a poll_enqueue(). Ah! Thanks, yes. I'll drop this patch. Amit