similar to: [PATCH] virtio_console: avoid config access from irq

Using control_work instead of config_work as the 3rd argument to container_of results in an invalid portdev pointer. Indeed, the work structure is initialized as below: INIT_WORK(&portdev->config_work, &config_work_handler); It leads to a crash when portdev->vdev is dereferenced later. This bug is triggered when the guest uses a virtio-console without multiport feature and

Using control_work instead of config_work as the 3rd argument to container_of results in an invalid portdev pointer. Indeed, the work structure is initialized as below: INIT_WORK(&portdev->config_work, &config_work_handler); It leads to a crash when portdev->vdev is dereferenced later. This bug is triggered when the guest uses a virtio-console without multiport feature and

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

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

when multiport is off, we don't initialize config work, but we then cancel uninitialized control_work on freeze. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/char/virtio_console.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index fae2dbb..def736d 100644 ---

when multiport is off, we don't initialize config work, but we then cancel uninitialized control_work on freeze. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/char/virtio_console.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index fae2dbb..def736d 100644 ---

We try to disable callbacks on c_ivq even without multiport even though that vq is not initialized in this configuration. Fixes: c743d09dbd01 ("virtio: console: Disable callbacks for virtqueues at start of S4 freeze") Suggested-by: Mike Galbraith <efault at gmx.de> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Hi Mike if you like, pls send me your Signed-off-by

We try to disable callbacks on c_ivq even without multiport even though that vq is not initialized in this configuration. Fixes: c743d09dbd01 ("virtio: console: Disable callbacks for virtqueues at start of S4 freeze") Suggested-by: Mike Galbraith <efault at gmx.de> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Hi Mike if you like, pls send me your Signed-off-by

On (Mon) 16 Jan 2017 [10:45:02], G. Campana wrote: > Using control_work instead of config_work as the 3rd argument to > container_of results in an invalid portdev pointer. Indeed, the work > structure is initialized as below: > > INIT_WORK(&portdev->config_work, &config_work_handler); > > It leads to a crash when portdev->vdev is dereferenced later. This

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:

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:

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add a virtio remoteproc serial driver: VIRTIO_ID_RPROC_SERIAL (0xB) for communicating with a remote processor in an asymmetric multi-processing configuration. The virtio remoteproc serial driver reuses the existing virtio_console implementation, and adds support for DMA allocation of data buffers but disables support for tty

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add a virtio remoteproc serial driver: VIRTIO_ID_RPROC_SERIAL (0xB) for communicating with a remote processor in an asymmetric multi-processing configuration. The virtio remoteproc serial driver reuses the existing virtio_console implementation, and adds support for DMA allocation of data buffers but disables support for tty

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add a simple serial connection driver called VIRTIO_ID_RPROC_SERIAL (11) for communicating with a remote processor in an asymmetric multi-processing configuration. This implementation reuses the existing virtio_console implementation, and adds support for DMA allocation of data buffers and disables use of tty console and the virtio

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add a simple serial connection driver called VIRTIO_ID_RPROC_SERIAL (11) for communicating with a remote processor in an asymmetric multi-processing configuration. This implementation reuses the existing virtio_console implementation, and adds support for DMA allocation of data buffers and disables use of tty console and the virtio

Pretty straight-forward, just use accessors for all fields. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- include/uapi/linux/virtio_console.h | 7 ++++--- drivers/char/virtio_console.c | 29 +++++++++++++++++------------ 2 files changed, 21 insertions(+), 15 deletions(-) diff --git a/include/uapi/linux/virtio_console.h b/include/uapi/linux/virtio_console.h index

Pretty straight-forward, just use accessors for all fields. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- include/uapi/linux/virtio_console.h | 7 ++++--- drivers/char/virtio_console.c | 29 +++++++++++++++++------------ 2 files changed, 21 insertions(+), 15 deletions(-) diff --git a/include/uapi/linux/virtio_console.h b/include/uapi/linux/virtio_console.h index

On Wed, Nov 13, 2019 at 04:00:56PM +0100, Laurent Vivier wrote: > When we hot unplug a virtserialport and then try to hot plug again, > it fails: > > (qemu) chardev-add socket,id=serial0,path=/tmp/serial0,server,nowait > (qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\ > chardev=serial0,id=serial0,name=serial0 > (qemu) device_del serial0 >

On Thu, 2019-11-14 at 13:25 +0100, Laurent Vivier wrote: > When we hot unplug a virtserialport and then try to hot plug again, > it fails: > > (qemu) chardev-add socket,id=serial0,path=/tmp/serial0,server,nowait > (qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\ > chardev=serial0,id=serial0,name=serial0 > (qemu) device_del serial0 > (qemu)

We currently allow multiple instances of the control work handler to run in parallel. This isn't expected to work; serialise access by disabling interrupts on new packets from the Host and enable them when all the existing ones are consumed. --- drivers/char/virtio_console.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/char/virtio_console.c