Displaying 20 results from an estimated 1000 matches similar to: "[PATCH 1/2] virtio: console: Fix crash when hot-unplugging a port and read is blocked"
2010 Sep 02
14
[PATCH 00/14] virtio: console: Hot-unplug fixes
Hey Rusty,
These are the patches that rework a few bits to make hot-unplug while
ports are open not crash apps (or kernels).
The problem is when hot-unplug is performed when a port is open, the
cdev struct is kept around by the file pointers and when the app later
does a 'close', things go boom-boom.
This patch series makes sure port as well as device hot-unplug is now
safe to perform
2010 Sep 02
14
[PATCH 00/14] virtio: console: Hot-unplug fixes
Hey Rusty,
These are the patches that rework a few bits to make hot-unplug while
ports are open not crash apps (or kernels).
The problem is when hot-unplug is performed when a port is open, the
cdev struct is kept around by the file pointers and when the app later
does a 'close', things go boom-boom.
This patch series makes sure port as well as device hot-unplug is now
safe to perform
2010 Mar 30
3
[PATCH 4/4] virtio: disable multiport console support.
Unfortunately there proved to be at least one bug which requires an
ABI change, so we're best off not introducing multiport support until
2.6.35.
While I generally left the multiport code paths intact, I really wanted
to remove the ABI defines from the header, which meant some quite deep cuts.
Signed-off-by: Rusty Russell <rusty at rustcorp.com.au>
To: Amit Shah <amit.shah at
2010 Mar 30
3
[PATCH 4/4] virtio: disable multiport console support.
Unfortunately there proved to be at least one bug which requires an
ABI change, so we're best off not introducing multiport support until
2.6.35.
While I generally left the multiport code paths intact, I really wanted
to remove the ABI defines from the header, which meant some quite deep cuts.
Signed-off-by: Rusty Russell <rusty at rustcorp.com.au>
To: Amit Shah <amit.shah at
2012 Apr 25
1
[PATCH 1/1] virtio: console: tell host of open ports after resume from s3/s4
If a port was open before going into one of the sleep states, the port
can continue normal operation after restore. However, the host has to
be told that the guest side of the connection is open to restore
pre-suspend state.
This wasn't noticed so far due to a bug in qemu that was fixed recently
(which marked the guest-side connection as always open).
CC: stable at vger.kernel.org # Only
2012 Apr 25
1
[PATCH 1/1] virtio: console: tell host of open ports after resume from s3/s4
If a port was open before going into one of the sleep states, the port
can continue normal operation after restore. However, the host has to
be told that the guest side of the connection is open to restore
pre-suspend state.
This wasn't noticed so far due to a bug in qemu that was fixed recently
(which marked the guest-side connection as always open).
CC: stable at vger.kernel.org # Only
2010 Mar 23
0
[PATCH 09/11] virtio: console: Don't always create a port 0 if using multiport
If we're using multiport, there's no point in always creating a console
port. Create the console port only if the host doesn't support
multiport.
Signed-off-by: Amit Shah <amit.shah at redhat.com>
---
drivers/char/virtio_console.c | 32 +++++++++++++++-----------------
1 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/drivers/char/virtio_console.c
2010 Mar 23
0
[PATCH 09/11] virtio: console: Don't always create a port 0 if using multiport
If we're using multiport, there's no point in always creating a console
port. Create the console port only if the host doesn't support
multiport.
Signed-off-by: Amit Shah <amit.shah at redhat.com>
---
drivers/char/virtio_console.c | 32 +++++++++++++++-----------------
1 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/drivers/char/virtio_console.c
2013 Jul 25
0
[PATCH v3 4/9] virtio: console: fix raising SIGIO after port unplug
SIGIO should be sent when a port gets unplugged. It should only be sent
to prcesses that have the port opened, and have asked for SIGIO to be
delivered. We were clearing out guest_connected before calling
send_sigio_to_port(), resulting in a sigio not getting sent to
processes.
Fix by setting guest_connected to false after invoking the sigio
function.
CC: <stable at vger.kernel.org>
2013 Jul 25
18
[PATCH v3 0/9] virtio: console: fixes for bugs and races with unplug
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
2013 Jul 25
18
[PATCH v3 0/9] virtio: console: fixes for bugs and races with unplug
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
2010 Feb 12
4
[PATCH 0/6] virtio: console: Fixes
Hey Rusty,
Here are a few fixes for virtio and virtio_console.
The first patch ensures the data elements of vqs are properly
initialised at allocation-time so that we don't trigger BUG_ONs. I found
this when hot-unplugging ports and there was just one unused buffer.
detach_unused_buffers() kept returning pointers that were invalid. I
didn't catch this earlier as I had the in_vq filled
2010 Feb 12
4
[PATCH 0/6] virtio: console: Fixes
Hey Rusty,
Here are a few fixes for virtio and virtio_console.
The first patch ensures the data elements of vqs are properly
initialised at allocation-time so that we don't trigger BUG_ONs. I found
this when hot-unplugging ports and there was just one unused buffer.
detach_unused_buffers() kept returning pointers that were invalid. I
didn't catch this earlier as I had the in_vq filled
2013 Jul 25
0
[PATCH v3 7/9] virtio: console: add locking in port unplug path
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
---
2013 Jul 29
1
[PATCH v3 1/9] virtio: console: fix race with port unplug and open/close
Amit Shah <amit.shah at redhat.com> writes:
> There's a window between find_port_by_devt() returning a port and us
> taking a kref on the port, where the port could get unplugged. Fix it
> by taking the reference in find_port_by_devt() itself.
>
> Problem reported and analyzed by Mateusz Guzik.
This fix is clearly correct, but what about the other find_port_by_*
2013 Jul 29
1
[PATCH v3 1/9] virtio: console: fix race with port unplug and open/close
Amit Shah <amit.shah at redhat.com> writes:
> There's a window between find_port_by_devt() returning a port and us
> taking a kref on the port, where the port could get unplugged. Fix it
> by taking the reference in find_port_by_devt() itself.
>
> Problem reported and analyzed by Mateusz Guzik.
This fix is clearly correct, but what about the other find_port_by_*
2010 Jan 29
3
virtio: console: Return -EFAULT on copy_xx_user errors, allow larger writes
Hey Rusty,
These updated patches in the series return -EFAULT on copy_xx_user
errors and also move the copy_from_user into fops_write() instead of it
being in send_buf. This enables send_buf to just read from kernel
buffers, making it simpler.
This also allows write()s to write more to the host in one go,
removingthe 4k limitation. I do limit the writes to 32k at once to not
put too much
2010 Jan 29
3
virtio: console: Return -EFAULT on copy_xx_user errors, allow larger writes
Hey Rusty,
These updated patches in the series return -EFAULT on copy_xx_user
errors and also move the copy_from_user into fops_write() instead of it
being in send_buf. This enables send_buf to just read from kernel
buffers, making it simpler.
This also allows write()s to write more to the host in one go,
removingthe 4k limitation. I do limit the writes to 32k at once to not
put too much
2013 Jul 19
12
[PATCH v2 00/11] virtio: console: fixes for port unplug
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
2013 Jul 19
12
[PATCH v2 00/11] virtio: console: fixes for port unplug
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