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

[Michal Privoznik <mprivozn@redhat.com>]

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