search for: unplug_ports

Amit Shah <amit.shah at redhat.com> 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

Amit Shah <amit.shah at redhat.com> 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

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 at redhat.com> >>> --- >>>

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 at redhat.com> >>> --- >>>

Jason Wang <jasowang at redhat.com> writes: > On 07/22/2013 01:45 PM, Rusty Russell wrote: >> Amit Shah <amit.shah at redhat.com> 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

Jason Wang <jasowang at redhat.com> writes: > On 07/22/2013 01:45 PM, Rusty Russell wrote: >> Amit Shah <amit.shah at redhat.com> 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

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

On 07/22/2013 01:45 PM, Rusty Russell wrote: > Amit Shah <amit.shah at redhat.com> 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

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

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

Commit c6017e793b93 ("virtio: console: add locks around buffer removal in port unplug path") added locking around the freeing of buffers in the vq. However, when free_buf() is called with can_sleep = true and rproc is enabled, it calls dma_free_coherent() directly, requiring interrupts to be enabled. Currently a WARNING is triggered due to the spin locking around free_buf, with a call

Commit c6017e793b93 ("virtio: console: add locks around buffer removal in port unplug path") added locking around the freeing of buffers in the vq. However, when free_buf() is called with can_sleep = true and rproc is enabled, it calls dma_free_coherent() directly, requiring interrupts to be enabled. Currently a WARNING is triggered due to the spin locking around free_buf, with a call

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

On 07/19/2013 04:16 AM, Amit Shah wrote: > We used to keep the port's char device structs and the /sys entries > around till the last reference to the port was dropped. This is > actually unnecessary, and resulted in buggy behaviour: > > 1. Open port in guest > 2. Hot-unplug port > 3. Hot-plug a port with the same 'name' property as the unplugged one > >

On 07/19/2013 04:16 AM, Amit Shah wrote: > We used to keep the port's char device structs and the /sys entries > around till the last reference to the port was dropped. This is > actually unnecessary, and resulted in buggy behaviour: > > 1. Open port in guest > 2. Hot-unplug port > 3. Hot-plug a port with the same 'name' property as the unplugged one > >

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Don't access uninitialized work-queue when removing device. The work queue is initialized only if the device multi-queue. So don't call cancel_work unless this is a multi-queue device. This fixes the following panic: Kernel panic - not syncing: BUG! Call Trace: 62031b28: [<6026085d>] panic+0x16b/0x2d3 62031b30: