On 07/23/2013 01:26 PM, Rusty Russell wrote: > Jason Wang <[email protected]> writes: >> On 07/22/2013 01:45 PM, Rusty Russell wrote: >>> Amit Shah <[email protected]> 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 <[email protected]> >>>>>>>> --- >>>>>>>> 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(). >> Yes, but the caller will wait then and since the wakeup was called >> before adding into waitqueue. It may block forever? > No, we enqueue then check: > > port = filp->private_data; > poll_wait(filp, &port->waitqueue, wait); > > if (!port->guest_connected) { > /* Port got unplugged */ > return POLLHUP; > } > ret = 0; > if (!will_read_block(port)) > ret |= POLLIN | POLLRDNORM; > if (!will_write_block(port)) > ret |= POLLOUT; > if (!port->host_connected) > ret |= POLLHUP; > > return ret; > > Which is the correct way to do this.
Right, thanks for the explaining. > > Cheers, > Rusty. _______________________________________________ Virtualization mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/virtualization
