search for: unplug_port

...>> >>> 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; &g...

...>> >>> 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; &g...

...&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: CPU0: CPU1: unplug_port() if (!port->guest_connected) { return POLLHUP; } wake_up_interruptiable() poll_wait(fil...

...&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: CPU0: CPU1: unplug_port() if (!port->guest_connected) { return POLLHUP; } wake_up_interruptiable() poll_wait(fil...

...f (!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) { >>&...

...f (!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) { >>&...

...); > >>> > >>> 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; > } >...

...>>> 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;...

Port unplug can race with close() in port_fops_release(). port_fops_release() already takes the necessary locks, ensure unplug_port() does that too. Signed-off-by: Amit Shah <amit.shah at redhat.com> --- drivers/char/virtio_console.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index 9cbed93..e8b707d 100644 --- a/drivers/char/virtio_console.c +++ b/d...

Hello, This series fixes a few bugs and races with port unplug and the various file operations: read(), write() and close(). I started coding up an alternative locking mechanism based on the discussion earlier in this series, but some of what we already have has to remain, and the new code is sufficiently different, so I'd rather it bakes for a while, and I ensure there are no regressions

Hello, This series fixes a few bugs and races with port unplug and the various file operations: read(), write() and close(). I started coding up an alternative locking mechanism based on the discussion earlier in this series, but some of what we already have has to remain, and the new code is sufficiently different, so I'd rather it bakes for a while, and I ensure there are no regressions

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 at redhat.com> > --- > drivers/char/virtio_console.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/char/virtio_console.c

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 at redhat.com> > --- > drivers/char/virtio_console.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/char/virtio_console.c

..._buf+0x1a8/0x288 Call Trace: [<8040c538>] show_stack+0x74/0xc0 [<80757240>] dump_stack+0xd0/0x110 [<80430d98>] __warn+0xfc/0x130 [<80430ee0>] warn_slowpath_null+0x2c/0x3c [<807e7c6c>] free_buf+0x1a8/0x288 [<807ea590>] remove_port_data+0x50/0xac [<807ea6a0>] unplug_port+0xb4/0x1bc [<807ea858>] virtcons_remove+0xb0/0xfc [<807b6734>] virtio_dev_remove+0x58/0xc0 [<807f918c>] __device_release_driver+0xac/0x134 [<807f924c>] device_release_driver+0x38/0x50 [<807f7edc>] bus_remove_device+0xfc/0x130 [<807f4b74>] device_del+0x17c/0x21c [...

..._buf+0x1a8/0x288 Call Trace: [<8040c538>] show_stack+0x74/0xc0 [<80757240>] dump_stack+0xd0/0x110 [<80430d98>] __warn+0xfc/0x130 [<80430ee0>] warn_slowpath_null+0x2c/0x3c [<807e7c6c>] free_buf+0x1a8/0x288 [<807ea590>] remove_port_data+0x50/0xac [<807ea6a0>] unplug_port+0xb4/0x1bc [<807ea858>] virtcons_remove+0xb0/0xfc [<807b6734>] virtio_dev_remove+0x58/0xc0 [<807f918c>] __device_release_driver+0xac/0x134 [<807f924c>] device_release_driver+0x38/0x50 [<807f7edc>] bus_remove_device+0xfc/0x130 [<807f4b74>] device_del+0x17c/0x21c [...

Hello, This series fixes a few bugs and races with port unplug and the various file operations: read(), write(), close() and poll(). There still might be more races lurking, but testing this series looks good to at least solve the easily-triggerable ones. I've run the virtio-serial testsuite and a few open/close/unplug tests, and haven't seen any badness. I've marked these patches

Hello, This series fixes a few bugs and races with port unplug and the various file operations: read(), write(), close() and poll(). There still might be more races lurking, but testing this series looks good to at least solve the easily-triggerable ones. I've run the virtio-serial testsuite and a few open/close/unplug tests, and haven't seen any badness. I've marked these patches

...;kobj, &port_attribute_group); > - device_destroy(pdrvdata.class, port->dev->devt); > - cdev_del(port->cdev); > - > - kfree(port->name); > - > - debugfs_remove(port->debugfs_file); > - > kfree(port); > } > > @@ -1566,6 +1558,14 @@ static void unplug_port(struct port *port) > */ > port->portdev = NULL; > > + sysfs_remove_group(&port->dev->kobj, &port_attribute_group); > + device_destroy(pdrvdata.class, port->dev->devt); > + cdev_del(port->cdev); > + > + kfree(port->name); > + > + debu...

...;kobj, &port_attribute_group); > - device_destroy(pdrvdata.class, port->dev->devt); > - cdev_del(port->cdev); > - > - kfree(port->name); > - > - debugfs_remove(port->debugfs_file); > - > kfree(port); > } > > @@ -1566,6 +1558,14 @@ static void unplug_port(struct port *port) > */ > port->portdev = NULL; > > + sysfs_remove_group(&port->dev->kobj, &port_attribute_group); > + device_destroy(pdrvdata.class, port->dev->devt); > + cdev_del(port->cdev); > + > + kfree(port->name); > + > + debu...

...51>] __mutex_unlock_slowpath+0x13d/0x148 62031c10: [<6004ef5e>] flush_work+0x0/0x1d7 62031c18: [<60050234>] try_to_grab_pending+0x0/0x17e 62031c38: [<6004e984>] get_work_gcwq+0x71/0x8f 62031c48: [<60050539>] __cancel_work_timer+0x5b/0x115 62031c78: [<628acc85>] unplug_port+0x0/0x191 [virtio_console] 62031c98: [<6005061c>] cancel_work_sync+0x12/0x14 62031ca8: [<628ace96>] virtcons_remove+0x80/0x15c [virtio_console] 62031ce8: [<628191de>] virtio_dev_remove+0x1e/0x7e [virtio] 62031d08: [<601cf242>] __device_release_driver+0x75/0xe4 62031d28:...