qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefano Garzarella <sgarzare@redhat.com>
To: pannengyuan <pannengyuan@huawei.com>,
	Stefan Hajnoczi <stefanha@gmail.com>
Cc: qemu devel list <qemu-devel@nongnu.org>,
	Michael Tsirkin <mst@redhat.com>,
	zhanghailiang <zhang.zhanghailiang@huawei.com>,
	Euler Robot <euler.robot@huawei.com>
Subject: Re: [PATCH] vhost-vsock: delete vqs in vhost_vsock_unrealize to avoid memleaks
Date: Tue, 14 Jan 2020 17:59:11 +0100	[thread overview]
Message-ID: <CAGxU2F7CC2bjUg=6P0UDYehKqyCq+kHc=hoyvSV8rPSj8oFAZg@mail.gmail.com> (raw)
In-Reply-To: <20200114164441.GG132666@stefanha-x1.localdomain>

On Tue, Jan 14, 2020 at 5:45 PM Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> On Tue, Jan 14, 2020 at 03:52:29PM +0800, pannengyuan@huawei.com wrote:
> > From: Pan Nengyuan <pannengyuan@huawei.com>
> >
> > Receive/transmit/event vqs forgot to cleanup in vhost_vsock_unrealize. This
> > patch save receive/transmit vq pointer in realize() and cleanup vqs
> > through those vq pointers in unrealize(). The leak stack is as follow:
> >
> > Direct leak of 21504 byte(s) in 3 object(s) allocated from:
> >   #0 0x7f86a1356970 (/lib64/libasan.so.5+0xef970)  ??:?
> >   #1 0x7f86a09aa49d (/lib64/libglib-2.0.so.0+0x5249d)  ??:?
> >   #2 0x5604852f85ca (./x86_64-softmmu/qemu-system-x86_64+0x2c3e5ca)  /mnt/sdb/qemu/hw/virtio/virtio.c:2333
> >   #3 0x560485356208 (./x86_64-softmmu/qemu-system-x86_64+0x2c9c208)  /mnt/sdb/qemu/hw/virtio/vhost-vsock.c:339
> >   #4 0x560485305a17 (./x86_64-softmmu/qemu-system-x86_64+0x2c4ba17)  /mnt/sdb/qemu/hw/virtio/virtio.c:3531
> >   #5 0x5604858e6b65 (./x86_64-softmmu/qemu-system-x86_64+0x322cb65)  /mnt/sdb/qemu/hw/core/qdev.c:865
> >   #6 0x5604861e6c41 (./x86_64-softmmu/qemu-system-x86_64+0x3b2cc41)  /mnt/sdb/qemu/qom/object.c:2102
> >
> > Reported-by: Euler Robot <euler.robot@huawei.com>
> > Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
> > ---
> >  hw/virtio/vhost-vsock.c         | 9 +++++++--
> >  include/hw/virtio/vhost-vsock.h | 2 ++
> >  2 files changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/virtio/vhost-vsock.c b/hw/virtio/vhost-vsock.c
> > index f5744363a8..896c0174c1 100644
> > --- a/hw/virtio/vhost-vsock.c
> > +++ b/hw/virtio/vhost-vsock.c
> > @@ -335,8 +335,10 @@ static void vhost_vsock_device_realize(DeviceState *dev, Error **errp)
> >                  sizeof(struct virtio_vsock_config));
> >
> >      /* Receive and transmit queues belong to vhost */
> > -    virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE, vhost_vsock_handle_output);
> > -    virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE, vhost_vsock_handle_output);
> > +    vsock->recv_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
> > +                                      vhost_vsock_handle_output);
> > +    vsock->trans_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
> > +                                       vhost_vsock_handle_output);
> >
> >      /* The event queue belongs to QEMU */
> >      vsock->event_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
> > @@ -378,6 +380,9 @@ static void vhost_vsock_device_unrealize(DeviceState *dev, Error **errp)
> >      /* This will stop vhost backend if appropriate. */
> >      vhost_vsock_set_status(vdev, 0);
> >
> > +    virtio_delete_queue(vsock->recv_vq);
> > +    virtio_delete_queue(vsock->trans_vq);
> > +    virtio_delete_queue(vsock->event_vq);
> >      vhost_dev_cleanup(&vsock->vhost_dev);
> >      virtio_cleanup(vdev);
> >  }
>
> Please delete the virtqueues after vhost cleanup (the reverse
> initialization order).  There is currently no reason why it has to be
> done in reverse initialization order, your patch should work too, but
> it's a good default for avoiding user-after-free bugs.
>

Agree!

Since we are here, should we delete the queues also in the error path
of vhost_vsock_device_realize()?

Thanks,
Stefano



  reply	other threads:[~2020-01-14 17:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-14  7:52 [PATCH] vhost-vsock: delete vqs in vhost_vsock_unrealize to avoid memleaks pannengyuan
2020-01-14  9:20 ` Stefano Garzarella
2020-01-14 16:44 ` Stefan Hajnoczi
2020-01-14 16:59   ` Stefano Garzarella [this message]
2020-01-15  1:34     ` Pan Nengyuan

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='CAGxU2F7CC2bjUg=6P0UDYehKqyCq+kHc=hoyvSV8rPSj8oFAZg@mail.gmail.com' \
    --to=sgarzare@redhat.com \
    --cc=euler.robot@huawei.com \
    --cc=mst@redhat.com \
    --cc=pannengyuan@huawei.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=zhang.zhanghailiang@huawei.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).