Jason Wang <jasowang@xxxxxxxxxx> writes:
> On 07/22/2013 01:45 PM, Rusty Russell wrote:
>> Amit Shah <amit.shah@xxxxxxxxxx> 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 <amit.shah@xxxxxxxxxx>
>>>>>>> ---
>>>>>>> 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.
Cheers,
Rusty.
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
