linux-stable.git/drivers/char/virtio_console.c, branch linux-4.1.y

virtio_console: free buffers after reset

2018-05-23T01:36:37+00:00

[ Upstream commit a7a69ec0d8e4a58be7db88d33cbfa2912807bb2b ]

Console driver is out of spec. The spec says:
	A driver MUST NOT decrement the available idx on a live
	virtqueue (ie. there is no way to “unexpose” buffers).
and it does exactly that by trying to detach unused buffers
without doing a device reset first.

Defer detaching the buffers until device unplug.

Of course this means we might get an interrupt for
a vq without an attached port now. Handle that by
discarding the consumed buffer.

Reported-by: Tiwei Bie 
Fixes: b3258ff1d6 ("virtio: Decrement avail idx on buffer detach")
Cc: stable@vger.kernel.org
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Sasha Levin

virtio_console: fix a crash in config_work_handler

2017-07-31T17:37:50+00:00

[ Upstream commit 8379cadf71c3ee8173a1c6fc1ea7762a9638c047 ]

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 receives a config_changed virtio interrupt.

Signed-off-by: G. Campana 
Reviewed-by: Amit Shah 
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Sasha Levin

virtio-console: avoid DMA from stack

2017-06-13T13:29:17+00:00

[ Upstream commit c4baad50297d84bde1a7ad45e50c73adae4a2192 ]

put_chars() stuffs the buffer it gets into an sg, but that buffer may be
on the stack. This breaks with CONFIG_VMAP_STACK=y (for me, it
manifested as printks getting turned into NUL bytes).

Signed-off-by: Omar Sandoval 
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Amit Shah 
Signed-off-by: Sasha Levin

virtio: console: Unlock vqs while freeing buffers

2016-11-26T03:57:03+00:00

[ Upstream commit 34563769e438d2881f62cf4d9badc4e589ac0ec0 ]

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 stack like this:

WARNING: CPU: 3 PID: 121 at ./include/linux/dma-mapping.h:433
free_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
[<807f4c38>] device_unregister+0x24/0x38
[<807b6b50>] unregister_virtio_device+0x28/0x44

Fix this by restructuring the loops to allow the locks to only be taken
where it is necessary to protect the vqs, and release it while the
buffer is being freed.

Fixes: c6017e793b93 ("virtio: console: add locks around buffer removal in port unplug path")
Cc: stable@vger.kernel.org
Signed-off-by: Matt Redfearn 
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Sasha Levin

virtio_console: Use bool function return values of true/false not 1/0

2015-04-03T14:15:30+00:00

Use the normal return values for bool functions

Signed-off-by: Joe Perches 
Reviewed-by: Amit Shah 
Signed-off-by: Greg Kroah-Hartman

virtio_console: avoid config access from irq

2015-03-05T03:06:18+00:00

when multiport is off, virtio console invokes config access from irq
context, config access is blocking on s390.
Fix this up by scheduling work from config irq - similar to what we do
for multiport configs.

Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Amit Shah 
Signed-off-by: Rusty Russell 
Cc: stable@kernel.org

virtio_console: init work unconditionally

2015-03-05T03:06:17+00:00

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 
Reviewed-by: Amit Shah 
Signed-off-by: Rusty Russell 
Cc: stable@kernel.org

virtio: don't require a config space on the console device.

2015-02-11T04:33:17+00:00

Strictly, it's only needed when we have features (size or multiport).

Signed-off-by: Rusty Russell

virtio/console: verify device has config space

2015-01-21T05:58:46+00:00

Some devices might not implement config space access
(e.g. remoteproc used not to - before 3.9).
virtio/console needs config space access so make it
fail gracefully if not there.

Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Rusty Russell

virtio_console: fix sparse warnings

2014-12-09T10:06:33+00:00

CHECK drivers/char/virtio_console.c
drivers/char/virtio_console.c:687:36: warning: incorrect type in
	argument 1 (different address spaces)
drivers/char/virtio_console.c:687:36:    expected void [noderef]
	*to
drivers/char/virtio_console.c:687:36:    got char *out_buf
drivers/char/virtio_console.c:790:35: warning: incorrect type in
	argument 2 (different address spaces)
drivers/char/virtio_console.c:790:35:    expected char *out_buf
drivers/char/virtio_console.c:790:35:    got char [noderef]
	*ubuf

fill_readbuf is reused with both kernel and userspace pointers,
depending on value of to_user flag.

Tag address parameter as __user, and cast to/from regular pointer type
when we know it's safe.

Signed-off-by: Michael S. Tsirkin