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);
 }
-- 
2.23.0

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.]

>  }

On 11/11/19 12:15 PM, Cornelia Huck wrote:
> 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?

Alright, I'll rename the function. I worry that if free is left as an 
exercise to caller then it'll be always forgotten about. That's why I 
put the call into close function.

Michal