qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michal Privoznik
Subject: Re: [PATCH 2/2] vfio-helpers: Free QEMUVFIOState in qemu_vfio_close()
Date: Tue, 12 Nov 2019 16:25:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1

On 11/11/19 12:15 PM, Cornelia Huck wrote:
On Mon, 11 Nov 2019 11:37:42 +0100
Michal Privoznik <address@hidden> 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 <address@hidden>
---
  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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]