Messages in this thread | | | Subject | Re: [PATCH v3] virtio_console: allocate inbufs in add_port() only if it is needed | From | Amit Shah <> | Date | Wed, 04 Dec 2019 14:58:51 +0100 |
| |
On Tue, 2019-12-03 at 10:42 -0500, Michael S. Tsirkin wrote: > On Tue, Dec 03, 2019 at 03:46:50PM +0100, Amit Shah wrote: > > 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) 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@redhat.com > > > Cc: stable@vger.kernel.org > > > Signed-off-by: Laurent Vivier <lvivier@redhat.com> > > > > Reviewed-by: Amit Shah <amit@kernel.org> > > > > Thanks! > > > Thanks, however this has already been merged by Linus. > I can't add the tag retroactively, sorry about that.
Right, no problem - but I wanted to ensure it's on-list :)
> > For bugfix patches like that, I think we can reasonably > target a turn around of a couple of days, these > shouldn't really need to wait weeks for review.
Sure, thanks for picking it up fast enough. Life happens, etc., and it's not always possible to reply in a couple of days. Since we had already covered the main comments in v1 and v2, v3 wasn't going to need much attention anyway.
| |