Re: [PATCH 2/2] vfio-helpers: Free QEMUVFIOState in qemu_vfio_close()

[Cornelia Huck <cohuck@redhat.com>]

On Mon, 11 Nov 2019 11:37:42 +0100
Michal Privoznik <mprivozn@redhat.com> wrote:

> The qemu_vfio_open_pci() allocates this QEMUVFIOState structure
> but free counterpart is missing. Since we already have
> qemu_vfio_close() which does cleanup of the state, it looks like
> a perfect place to free the structure too.
> 
> ==178278== 528 (360 direct, 168 indirect) bytes in 1 blocks are definitely lost in loss record 6,605 of 6,985
> ==178278==    at 0x4A35476: calloc (vg_replace_malloc.c:752)
> ==178278==    by 0x51B1158: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6000.6)
> ==178278==    by 0xA68613: qemu_vfio_open_pci (vfio-helpers.c:428)
> ==178278==    by 0x9779EA: nvme_init (nvme.c:606)
> ==178278==    by 0x97830F: nvme_file_open (nvme.c:795)
> ==178278==    by 0x8E9439: bdrv_open_driver (block.c:1293)
> ==178278==    by 0x8E9E1C: bdrv_open_common (block.c:1553)
> ==178278==    by 0x8ED264: bdrv_open_inherit (block.c:3083)
> ==178278==    by 0x8ED79D: bdrv_open (block.c:3176)
> ==178278==    by 0x5DA5C1: bds_tree_init (blockdev.c:670)
> ==178278==    by 0x5E2B64: qmp_blockdev_add (blockdev.c:4354)
> ==178278==    by 0x5ECB1D: configure_blockdev (vl.c:1202)
> 
> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
> ---
>  util/vfio-helpers.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/util/vfio-helpers.c b/util/vfio-helpers.c
> index 813f7ec564..5ff91c1e5c 100644
> --- a/util/vfio-helpers.c
> +++ b/util/vfio-helpers.c
> @@ -721,4 +721,5 @@ void qemu_vfio_close(QEMUVFIOState *s)
>      close(s->device);
>      close(s->group);
>      close(s->container);
> +    g_free(s);

Not sure if freeing the parameter passed in via a function called
'close' isn't too surprising... it's not that obvious that the caller
is also relinquishing its reference to the QEMUVFIOState; maybe rename
the function to qemu_vfio_close_and_free() or so?

[Looking at the blockdev code, it uses the pattern of first closing the
bs and then freeing it separately, which is a bit odd as the only call
to bdrv_close (which will eventually end up here for nvme) is
immediately followed by a g_free. Just something I noticed.]

>  }