All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Laurent Vivier <lvivier@redhat.com>
Cc: linux-kernel@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Amit Shah <amit@kernel.org>,
	virtualization@lists.linux-foundation.org,
	stable@vger.kernel.org
Subject: Re: [PATCH v2] virtio_console: allocate inbufs in add_port() only if it is needed
Date: Wed, 13 Nov 2019 14:28:42 -0500	[thread overview]
Message-ID: <20191113142757-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <7bd34d61-146f-8edb-d82d-7285a83437b4@redhat.com>

On Wed, Nov 13, 2019 at 05:37:34PM +0100, Laurent Vivier wrote:
> On 13/11/2019 16:22, Michael S. Tsirkin wrote:
> > On Wed, Nov 13, 2019 at 10:21:11AM -0500, Michael S. Tsirkin wrote:
> >> On Wed, Nov 13, 2019 at 04:00:56PM +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>
> >>> ---
> >>>
> >>> Notes:
> >>>     v2: making fill_queue return int and testing return code for -ENOSPC
> >>>
> >>>  drivers/char/virtio_console.c | 24 +++++++++---------------
> >>>  1 file changed, 9 insertions(+), 15 deletions(-)
> >>>
> >>> diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
> >>> index 7270e7b69262..9e6534fd1aa4 100644
> >>> --- a/drivers/char/virtio_console.c
> >>> +++ b/drivers/char/virtio_console.c
> >>> @@ -1325,24 +1325,24 @@ static void set_console_size(struct port *port, u16 rows, u16 cols)
> >>>  	port->cons.ws.ws_col = cols;
> >>>  }
> >>>  
> >>> -static unsigned int fill_queue(struct virtqueue *vq, spinlock_t *lock)
> >>> +static int fill_queue(struct virtqueue *vq, spinlock_t *lock)
> >>>  {
> >>>  	struct port_buffer *buf;
> >>> -	unsigned int nr_added_bufs;
> >>> +	int nr_added_bufs;
> >>>  	int ret;
> >>>  
> >>>  	nr_added_bufs = 0;
> >>>  	do {
> >>>  		buf = alloc_buf(vq->vdev, PAGE_SIZE, 0);
> >>>  		if (!buf)
> >>> -			break;
> >>> +			return -ENOMEM;
> >>>  
> >>>  		spin_lock_irq(lock);
> >>>  		ret = add_inbuf(vq, buf);
> >>>  		if (ret < 0) {
> >>>  			spin_unlock_irq(lock);
> >>>  			free_buf(buf, true);
> >>> -			break;
> >>> +			return ret;
> >>>  		}
> >>>  		nr_added_bufs++;
> >>>  		spin_unlock_irq(lock);
> > 
> > So actually, how about handling ENOSPC specially here, and
> > returning success? After all queue is full as requested ...
> 
> I think it's interesting to return -ENOSPC to manage it as a real error
> in virtcons_probe() as in this function the queue should not be already
> full (is this right?) and to return the real error code.
> 
> Thanks,
> Laurent

OK then. Pls add comments.


  parent reply	other threads:[~2019-11-13 19:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-13 15:00 [PATCH v2] virtio_console: allocate inbufs in add_port() only if it is needed Laurent Vivier
2019-11-13 15:21 ` Michael S. Tsirkin
2019-11-13 15:21 ` Michael S. Tsirkin
2019-11-13 15:22   ` Michael S. Tsirkin
2019-11-13 15:22   ` Michael S. Tsirkin
2019-11-13 16:37     ` Laurent Vivier
2019-11-13 19:28       ` Michael S. Tsirkin
2019-11-13 19:28       ` Michael S. Tsirkin [this message]
2019-11-13 16:37     ` Laurent Vivier
  -- strict thread matches above, loose matches on Subject: below --
2019-11-13 15:00 Laurent Vivier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191113142757-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=amit@kernel.org \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lvivier@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.