On Mon, Nov 25, 2019 at 06:44:05PM +0100, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@xxxxxxxxxxxxxxx>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From d791cfcbf98191122af70b053a21075cb450d119 Mon Sep 17 00:00:00 2001
From: Laurent Vivier <lvivier@xxxxxxxxxx>
Date: Thu, 14 Nov 2019 13:25:48 +0100
Subject: [PATCH] virtio_console: allocate inbufs in add_port() only if it is
needed
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) device_add virtserialport,bus=virtio-serial0.0,nr=2,\
chardev=serial0,id=serial0,name=serial0
kernel error:
virtio-ports vport2p2: Error allocating inbufs
qemu error:
virtio-serial-bus: Guest failure in adding port 2 for device \
virtio-serial0.0
This happens because buffers for the in_vq are allocated when the port is
added but are not released when the port is unplugged.
They are only released when virtconsole is removed (see a7a69ec0d8e4)
To avoid the problem and to be symmetric, we could allocate all the buffers
in init_vqs() as they are released in remove_vqs(), but it sounds like
a waste of memory.
Rather than that, this patch changes add_port() logic to ignore ENOSPC
error in fill_queue(), which means queue has already been filled.
Fixes: a7a69ec0d8e4 ("virtio_console: free buffers after reset")
Cc: mst@xxxxxxxxxx
Cc: stable@xxxxxxxxxxxxxxx
Signed-off-by: Laurent Vivier <lvivier@xxxxxxxxxx>
Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx>
I took the following two commits as well and queued all 3 for 4.9 and
4.4:
2855b33514d2 ("virtio_console: don't tie bufs to a vq")
5c60300d68da ("virtio_console: reset on out of memory")
--
Thanks,
Sasha
