Re: [PATCH v3] virtio_console: allocate inbufs in add_port() only if it is needed
From: Amit Shah
Date: Wed Dec 04 2019 - 08:58:57 EST
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@xxxxxxxxxx
> > > Cc: stable@xxxxxxxxxxxxxxx
> > > Signed-off-by: Laurent Vivier <lvivier@xxxxxxxxxx>
> >
> > Reviewed-by: Amit Shah <amit@xxxxxxxxxx>
> >
> > 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.