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

virtio_console: free buffers after reset

2018-05-02T14:59:54+00:00

commit a7a69ec0d8e4a58be7db88d33cbfa2912807bb2b upstream.

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: Greg Kroah-Hartman

virtio-console: avoid DMA from stack

2017-04-22T05:15:02+00:00

commit c4baad50297d84bde1a7ad45e50c73adae4a2192 upstream.

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 
Cc: Ben Hutchings 
Cc: Brad Spengler 
Signed-off-by: Greg Kroah-Hartman

virtio: console: Unlock vqs while freeing buffers

2016-11-24T04:09:12+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: avoid config access from irq

2015-03-28T13:36:55+00:00

[ Upstream commit eeb8a7e8bb123e84daeef84f5a2eab99ad2839a2 ]

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
Signed-off-by: Sasha Levin

virtio_console: init work unconditionally

2015-03-28T13:36:47+00:00

[ Upstream commit 4f6e24ed9de8634d6471ef86b382cba6d4e57ca8 ]

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
Signed-off-by: Sasha Levin

virtio_console: move early VQ enablement

2014-11-13T07:53:26+00:00

Commit f5866db6 (virtio_console: enable VQs early) tried to make
sure that DRIVER_OK was set when virtio_console started using its
virtqueues. Doing this in add_port(), however, means that we try
to set DRIVER_OK again when when a port is dynamically added after
the probe function is done.

Let's move virtio_device_ready() to the probe function just before
trying to use the virtqueues instead. This is fine as nothing can
fail inbetween.

Reported-by: Thomas Graf 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Cornelia Huck 

Signed-off-by: Michael S. Tsirkin

virtio_console: enable VQs early on restore

2014-10-14T23:55:09+00:00

virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after resume returns, virtio console violated this
rule by adding inbufs, which causes the VQ to be used directly within
restore.

To fix, call virtio_device_ready before using VQs.

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

virtio_console: enable VQs early

2014-10-14T23:55:03+00:00

virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after probe returns, virtio console violated this
rule by adding inbufs, which causes the VQ to be used directly within
probe.

To fix, call virtio_device_ready before using VQs.

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

virtio: console: remove unnecessary null test before debugfs_remove_recursive

2014-07-27T11:37:14+00:00

Fix checkpatch warning:
WARNING: debugfs_remove_recursive(NULL) is safe this check is probably not required

Cc: Arnd Bergmann 
Cc: virtualization@lists.linux-foundation.org
Reviewed-by: Amit Shah 
Signed-off-by: Fabian Frederick 
Signed-off-by: Rusty Russell

pipe: kill ->map() and ->unmap()

2014-04-02T03:19:19+00:00

all pipe_buffer_operations have the same instances of those...

Signed-off-by: Al Viro