[PATCH] target/i386/hax-posix: fix two 'format-truncation' compile warnings

From: Pan Nengyuan Fix compile warnings: /mnt/sdb/qemu-new/qemu_test/qemu/target/i386/hax-posix.c:124:56: error: ‘%02d’ directive output may be truncated writing between 2 and 11 bytes into a region of size 3 [-Werror=format-truncation=] snprintf(name, sizeof HAX_VM_DEVFS, "/dev/hax_vm/vm%

[PATCH v2 0/2] delete virtio queues in vhost-user-blk-unrealize

From: Pan Nengyuan This series patch fix memleaks when detaching vhost-user-blk device. 1. use old virtio_del_queue to fix memleaks, it's easier for stable branches to merge. As the discussion in https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg02903.html 2. convert virtio_del_qu

[PATCH v2 2/2] vhost-use-blk: convert to new virtio_delete_queue

From: Pan Nengyuan use the new virtio_delete_queue function to cleanup. Signed-off-by: Pan Nengyuan --- V2->V1: - rename vqs to vhost_vqs to avoid confusing with virtqs (suggented by Stefan Hajnoczi) --- hw/block/vhost-user-blk.c | 19 +++ include/hw/virtio/vhost-user

[PATCH v2 1/2] vhost-user-blk: delete virtioqueues in unrealize to fix memleaks

From: Pan Nengyuan virtio queues forgot to delete in unrealize, and aslo error path in realize, this patch fix these memleaks, the leak stack is as follow: Direct leak of 114688 byte(s) in 16 object(s) allocated from: #0 0x7f24024fdbf0 in calloc (/lib64/libasan.so.3+0xcabf0) #1 0x7f24016

[PATCH] migration/savevm: release gslist after dump_vmstate_json

From: Pan Nengyuan 'list' forgot to free at the end of dump_vmstate_json_to_file(), although it's called only once, but seems like a clean code. Fix the leak as follow: Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x7fb946abd768 in __interceptor_malloc (/lib64/libasan.so.5+0x

[PATCH v2 2/2] hw: move timer_new from init() into realize() to avoid memleaks

From: Pan Nengyuan There are some memleaks when we call 'device_list_properties'. This patch move timer_new from init into realize to fix it. Meanwhile, do the null check in mos6522_reset() to avoid null deref if we move timer_new into realize(). Reported-by: Euler Robot Signed-off-by: Pan Ne

[PATCH v2 1/2] s390x: fix memleaks in cpu_finalize

From: Pan Nengyuan This patch fix memleaks when we call tests/qtest/cpu-plug-test on s390x. The leak stack is as follow: Direct leak of 48 byte(s) in 1 object(s) allocated from: #0 0x7fb43c7cd970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970) #1 0x7fb43be2149d in g_malloc0 (/lib6

[PATCH v2 0/2] delay timer_new from init to realize to fix memleaks.

From: Pan Nengyuan v1: - Delay timer_new() from init() to realize() to fix memleaks. v2: - Similarly to other cleanups, move timer_new into realize in target/s390x/cpu.c (Suggested by Philippe Mathieu-Daudé). - Send these two patches as a series instead of sending each as a single patc

[PATCH 2/2] hw: move timer_new from init() into realize() to avoid memleaks

From: Pan Nengyuan There are some memleaks when we call 'device_list_properties'. This patch move timer_new from init into realize to fix it. Meanwhile, do the null check in mos6522_reset() to avoid null deref if we move timer_new into realize(). Reported-by: Euler Robot Signed-off-by: Pan Ne

[PATCH 1/2] s390x: fix memleaks in cpu_finalize

From: Pan Nengyuan This patch fix memleaks when we call tests/qtest/cpu-plug-test on s390x. The leak stack is as follow: Direct leak of 48 byte(s) in 1 object(s) allocated from: #0 0x7fb43c7cd970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970) #1 0x7fb43be2149d in g_malloc0 (/lib6

[PATCH] ppc: free 'fdt' after reset the machine

From: Pan Nengyuan 'fdt' forgot to clean both e500 and pnv when we call 'system_reset' on ppc, this patch fix it. The leak stacks are as follow: Direct leak of 4194304 byte(s) in 4 object(s) allocated from: #0 0x7fafe37dd970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970) #1 0x7faf

[PATCH 0/2] delete virtio queues in vhost-user-blk-unrealize

From: Pan Nengyuan This series patch fix memleaks when detaching vhost-user-blk device. 1. use old virtio_del_queue to fix memleaks, it's easier for stable branches to merge. As the discussion in https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg02903.html 2. convert virtio_del_qu

[PATCH 2/2] vhost-use-blk: convert to new virtio_delete_queue

From: Pan Nengyuan use the new virtio_delete_queue function to cleanup. Signed-off-by: Pan Nengyuan --- hw/block/vhost-user-blk.c | 11 +++ include/hw/virtio/vhost-user-blk.h | 1 + 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/hw/block/vhost-user-blk.c b/hw/

[PATCH 1/2] vhost-user-blk: delete virtioqueues in unrealize to fix memleaks

From: Pan Nengyuan virtio queues forgot to delete in unrealize, and aslo error path in realize, this patch fix these memleaks, the leak stack is as follow: Direct leak of 114688 byte(s) in 16 object(s) allocated from: #0 0x7f24024fdbf0 in calloc (/lib64/libasan.so.3+0xcabf0) #1 0x7f24016

[PATCH] migration-test: fix some memleaks in migration-test

From: Pan Nengyuan spotted by asan, 'check-qtest-aarch64' runs fail if sanitizers is enabled. Reported-by: Euler Robot Signed-off-by: Pan Nengyuan --- tests/qtest/migration-test.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/tests/qtest/migration-test.c

[PATCH 3/3] stellaris: delay timer_new to avoid memleaks

From: Pan Nengyuan There is a memory leak when we call 'device_list_properties' with typename = stellaris-gptm. It's easy to reproduce as follow: virsh qemu-monitor-command vm1 --pretty '{"execute": "device-list-properties", "arguments": {"typename": "stellaris-gptm"}}' This patch delay tim

[PATCH 1/3] armv7m_systick: delay timer_new to avoid memleaks

From: Pan Nengyuan There is a memory leak when we call 'device_list_properties' with typename = armv7m_systick. It's easy to reproduce as follow: virsh qemu-monitor-command vm1 --pretty '{"execute": "device-list-properties", "arguments": {"typename": "armv7m_systick"}}' This patch delay tim

[PATCH 2/3] stm32f2xx_timer: delay timer_new to avoid memleaks

From: Pan Nengyuan There is a memory leak when we call 'device_list_properties' with typename = stm32f2xx_timer. It's easy to reproduce as follow: virsh qemu-monitor-command vm1 --pretty '{"execute": "device-list-properties", "arguments": {"typename": "stm32f2xx_timer"}}' This patch delay

[PATCH 0/3] delay timer_new to avoid memleaks

From: Pan Nengyuan This series delay timer_new into realize() to fix some memleaks when we call 'device-list-properties'. Pan Nengyuan (3): armv7m_systick: delay timer_new to avoid memleaks stm32f2xx_timer: delay timer_new to avoid memleaks stellaris: delay timer_new to avoid memleaks h

[PATCH v2] pl031: add finalize function to avoid memleaks

From: Pan Nengyuan There is a memory leak when we call 'device_list_properties' with typename = pl031. It's easy to reproduce as follow: virsh qemu-monitor-command vm1 --pretty '{"execute": "device-list-properties", "arguments": {"typename": "pl031"}}' The memory leak stack: Direct leak of

[PATCH] pl031: add finalize function to avoid memleaks

From: Pan Nengyuan There is a memory leak when we call 'device_list_properties' with typename = pl031. It's easy to reproduce as follow: virsh qemu-monitor-command vm1 --pretty '{"execute": "device-list-properties", "arguments": {"typename": "pl031"}}' The memory leak stack: Direct leak of

[PATCH] boot-order-test: fix memleaks in boot-order-test

From: Pan Nengyuan It's not a big deal, but 'check qtest-ppc/ppc64' runs fail if sanitizers is enabled. The memory leak stack is as follow: Direct leak of 128 byte(s) in 4 object(s) allocated from: #0 0x7f11756f5970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970) #1 0x7f1174f2549d

[PATCH] stm32f4xx_syscfg: remove redundant code to fix coverity warning

From: Pan Nengyuan Fixes the coverity warning: CID 91708242: (EVALUATION_ORDER) 50. write_write_typo: In "config = config = irq / 16", "config" is written twice with the same value. 50uint8_t config = config = irq / 16; Reported-by: Euler Robot Signed-off-by: Pan Nengyuan ---

[PATCH] backup-top: fix a memory leak in bdrv_backup_top_append()

From: Pan Nengyuan top->opaque is aleardy malloced in bdrv_new_open_driver(), and then change the pointer but without freeing it. It will cause a memory leak, the leak stack is as follow: Direct leak of 24 byte(s) in 1 object(s) allocated from: #0 0x7ff6f7be4970 (/lib64/libasan.so.5+0xef970)

[PATCH 2/2] virtio-scsi: convert to new virtio_delete_queue

From: Pan Nengyuan Use virtio_delete_queue to make it more clear. Signed-off-by: Pan Nengyuan --- hw/scsi/virtio-scsi.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c index 858b3aaccb..d3af42ef92 100644 --- a/hw/scsi/virt

[PATCH 1/2] virtio-scsi: delete vqs in unrealize to avoid memleaks

From: Pan Nengyuan This patch fix memleaks when attaching/detaching virtio-scsi device, the memory leak stack is as follow: Direct leak of 21504 byte(s) in 3 object(s) allocated from: #0 0x7f491f2f2970 (/lib64/libasan.so.5+0xef970) ??:? #1 0x7f491e94649d (/lib64/libglib-2.0.so.0+0x5249d) ?

[PATCH 0/2] delete virtio queues in virtio_scsi_unrealize

From: Pan Nengyuan This serie patch fix memleaks when detaching virtio-scsi device. 1. use old virtio_del_queue to fix memleaks, it's easier for stable branches to merge. As the discussion in https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg02903.html 2. replace virtio_del_queue

[PATCH v2 2/2] virtio-9p-device: convert to new virtio_delete_queue

From: Pan Nengyuan Use virtio_delete_queue to make it more clear. Signed-off-by: Pan Nengyuan --- Changes V2 to V1: - replace virtio_del_queue to virtio_delete_queue to make it more clear. --- hw/9pfs/virtio-9p-device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/9pf

[PATCH v2 0/2] fix memleaks in virtio_9p_device_unrealize

From: Pan Nengyuan v1: fix memleaks in virtio_9p_device_unrealize v2: split patch to make it easier for stable branches to merge Pan Nengyuan (2): virtio-9p-device: fix memleak in virtio_9p_device_unrealize virtio-9p-device: convert to new virtio_delete_queue hw/9pfs/virtio-9p-device.c | 1

[PATCH v2 1/2] virtio-9p-device: fix memleak in virtio_9p_device_unrealize

From: Pan Nengyuan v->vq forgot to cleanup in virtio_9p_device_unrealize, the memory leak stack is as follow: Direct leak of 14336 byte(s) in 2 object(s) allocated from: #0 0x7f819ae43970 (/lib64/libasan.so.5+0xef970) ??:? #1 0x7f819872f49d (/lib64/libglib-2.0.so.0+0x5249d) ??:? #2 0x55a

[PATCH] block: fix memleaks in bdrv_refresh_filename

From: Pan Nengyuan If we call the qmp 'query-block' while qemu is working on 'block-commit', it will cause memleaks, the memory leak stack is as follow: Indirect leak of 12360 byte(s) in 3 object(s) allocated from: #0 0x7f80f0b6d970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970) #

[PATCH v2] vhost-vsock: delete vqs in vhost_vsock_unrealize to avoid memleaks

From: Pan Nengyuan 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:

[PATCH v2] scsi-disk: define props in scsi_block_disk to avoid memleaks

From: Pan Nengyuan scsi_block_realize() use scsi_realize() to init some props, but these props is not defined in scsi_block_disk_properties, so they will not be freed. This patch defines these prop in scsi_block_disk_properties and aslo calls scsi_unrealize to avoid memleaks, the leak stack as f

[PATCH] vhost-vsock: delete vqs in vhost_vsock_unrealize to avoid memleaks

From: Pan Nengyuan 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:

[PATCH] virtio-9p-device: fix memleak in virtio_9p_device_unrealize

From: Pan Nengyuan v->vq forgot to cleanup in virtio_9p_device_unrealize, the memory leak stack is as follow: Direct leak of 14336 byte(s) in 2 object(s) allocated from: #0 0x7f819ae43970 (/lib64/libasan.so.5+0xef970) ??:? #1 0x7f819872f49d (/lib64/libglib-2.0.so.0+0x5249d) ??:? #2 0x55a

[PATCH] scsi-disk: define props in scsi_block_disk to avoid memleaks

From: Pan Nengyuan scsi_block_realize() use scsi_realize() to init some props, but these props is not defined in scsi_block_disk_properties, so they will not be freed. This patch defines these prop in scsi_block_disk_properties and aslo calls scsi_unrealize to avoid memleaks, the leak stack as f

[PATCH v2 1/2] vl: Don't mismatch g_strsplit()/g_free()

From: Pan Nengyuan It's a mismatch between g_strsplit and g_free, it will cause a memory leak as follow: [root@localhost]# ./aarch64-softmmu/qemu-system-aarch64 -accel help Accelerators supported in QEMU binary: tcg kvm = ==1207900

[PATCH v2 0/2] fix mismatches between g_strsplit and g_free

From: Pan Nengyuan v1: fix a mismatch in vl.c v2: fix mismatch in vl.c and qga/main.c Pan Nengyuan (2): vl: Don't mismatch g_strsplit()/g_free() qga/main: Don't mismatch g_strsplit/g_free in split_list() qga/main.c | 2 +- vl.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)

[PATCH v2 2/2] qga/main: Don't mismatch g_strsplit/g_free in split_list()

From: Pan Nengyuan fix a mismatch between g_strsplit and g_free Reported-by: Laurent Vivier Signed-off-by: Pan Nengyuan --- Changes v2 to v1: - fix a mismatch in qga/main.c --- qga/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/qga/main.c b/qga/main.c index c35c2a2

[PATCH] vl: Don't mismatch g_strsplit()/g_free()

From: Pan Nengyuan It's a mismatch between g_strsplit and g_free, it will cause a memory leak as follow: [root@localhost]# ./aarch64-softmmu/qemu-system-aarch64 -accel help Accelerators supported in QEMU binary: tcg kvm = ==1207900

[PATCH v2] nbd: fix uninitialized variable warning

From: Pan Nengyuan Fixes: /mnt/sdb/qemu/nbd/server.c: In function 'nbd_handle_request': /mnt/sdb/qemu/nbd/server.c:2313:9: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized] int ret; Reported-by: Euler Robot Signed-off-by: Pan Nengyuan --- Changes v2 to

[PATCH v2] arm/translate-a64: fix uninitialized variable warning

From: Pan Nengyuan Fixes: target/arm/translate-a64.c: In function 'disas_crypto_three_reg_sha512': target/arm/translate-a64.c:13625:9: error: 'genfn' may be used uninitialized in this function [-Werror=maybe-uninitialized] genfn(tcg_rd_ptr, tcg_rn_ptr, tcg_rm_ptr); ^~

[PATCH] arm/translate-a64: fix uninitialized variable warning

From: Pan Nengyuan Fixes: target/arm/translate-a64.c: In function 'disas_crypto_three_reg_sha512': target/arm/translate-a64.c:13625:9: error: 'genfn' may be used uninitialized in this function [-Werror=maybe-uninitialized] genfn(tcg_rd_ptr, tcg_rn_ptr, tcg_rm_ptr); ^~

[PATCH] nbd: fix uninitialized variable warning

From: Pan Nengyuan Fixes: /mnt/sdb/qemu/nbd/server.c: In function 'nbd_handle_request': /mnt/sdb/qemu/nbd/server.c:2313:9: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized] int ret; Reported-by: Euler Robot Signed-off-by: Pan Nengyuan --- nbd/server.c

[PATCH] util/module: fix a memory leak

From: Pan Nengyuan spotted by ASAN Fixes: 81d8ccb1bea4fb9eaaf4c8e30bd4021180a9a39f Reported-by: Euler Robot Signed-off-by: Pan Nengyuan --- util/module.c | 1 + 1 file changed, 1 insertion(+) diff --git a/util/module.c b/util/module.c index e9fe3e5..8c5315a 100644 --- a/util/module.c +++ b/u

[PATCH V2] vhost-user-test: fix a memory leak

From: Pan Nengyuan Spotted by ASAN. Reported-by: Euler Robot Signed-off-by: Pan Nengyuan --- Changes V2 to V1: - use a "goto cleanup", instead of duplicating the "free" functions. - free "dest_cmdline" at the end. --- tests/vhost-user-test.c | 5 - 1 file changed, 4 insertions(+), 1 delet

[PATCH] vhost-user-test: fix a memory leak

From: Pan Nengyuan Spotted by ASAN. Reported-by: Euler Robot Signed-off-by: Pan Nengyuan --- tests/vhost-user-test.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/vhost-user-test.c b/tests/vhost-user-test.c index 91ea373..54be931 100644 --- a/tests/vhost-user-test.c +++ b/tests/

[PATCH] riscv/sifive_u: fix a memory leak in soc_realize()

From: Pan Nengyuan Fix a minor memory leak in riscv_sifive_u_soc_realize() Reported-by: Euler Robot Signed-off-by: Pan Nengyuan --- hw/riscv/sifive_u.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c index 0140e95..0e12b3c 100644 --- a/hw/riscv/si

[PATCH v3 3/3] virtio-serial-bus: fix memory leak while attach virtio-serial-bus

From: Pan Nengyuan ivqs/ovqs/c_ivq/c_ovq forgot to cleanup in virtio_serial_device_unrealize, the memory leak stack is as below: Direct leak of 1290240 byte(s) in 180 object(s) allocated from: #0 0x7fc9bfc27560 in calloc (/usr/lib64/libasan.so.3+0xc7560) #1 0x7fc9bed6f015 in g_malloc0 (/

[PATCH v3 2/3] virtio-balloon: fix memory leak while attach virtio-balloon device

From: Pan Nengyuan ivq/dvq/svq/free_page_vq forgot to cleanup in virtio_balloon_device_unrealize, the memory leak stack is as follow: Direct leak of 14336 byte(s) in 2 object(s) allocated from: #0 0x7f99fd9d8560 in calloc (/usr/lib64/libasan.so.3+0xc7560) #1 0x7f99fcb20015 in g_malloc0 (

[PATCH v3 0/3] virtio: fix memory leak in virtio-balloon/virtio-serial-bus

From: Pan Nengyuan This series add a new function to cleanup vqueue through a vq pointer, and fix memory leaks in virtio-balloon and virtio-serial-bus. --- Changes v2 to v1: - add a new function to cleanup vqueue through a vq pointer. --- Changes v3 to v2: - change function name from virtio_del

[PATCH v3 1/3] virtio: add ability to delete vq through a pointer

From: Michael S. Tsirkin Devices tend to maintain vq pointers, allow deleting them through a vq pointer. Signed-off-by: Michael S. Tsirkin Signed-off-by: Pan Nengyuan [PMM: change function name to virtio_queue_cleanup; set used_elems to NULL after free] Cc: Amit Shah Reviewed-by: Pankaj Gup

[PATCH v5 2/2] block/nbd: fix memory leak in nbd_open()

From: Pan Nengyuan In currently implementation there will be a memory leak when nbd_client_connect() returns error status. Here is an easy way to reproduce: 1. run qemu-iotests as follow and check the result with asan: ./check -raw 143 Following is the asan output backtrack: Direct leak of

[PATCH v5 1/2] block/nbd: extract the common cleanup code

From: Pan Nengyuan The BDRVNBDState cleanup code is common in two places, add nbd_clear_bdrvstate() function to do these cleanups. Signed-off-by: Stefano Garzarella Signed-off-by: Pan Nengyuan Reviewed-by: Vladimir Sementsov-Ogievskiy --- v3: - new patch, split form 2/2 patch (suggested by St

[PATCH v5 0/2] block/nbd: fix memory leak in nbd_open

From: Pan Nengyuan This series add a new function to do the common cleanups, and fix a memory leak in nbd_open when nbd_client_connect returns error status. --- Changes v2 to v1: - add a new function to do the common cleanups (suggested by Stefano Garzarella). --- Changes v3 to v2: - split in t

[PATCH v4 1/2] block/nbd: extract the common cleanup code

From: Pan Nengyuan The BDRVNBDState cleanup code is common in two places, add nbd_clear_bdrvstate() function to do these cleanups. Signed-off-by: Stefano Garzarella Signed-off-by: Pan Nengyuan Reviewed-by: Vladimir Sementsov-Ogievskiy --- v3: - new patch, split form 2/2 patch (suggested by St

[PATCH v4 2/2] block/nbd: fix memory leak in nbd_open()

From: Pan Nengyuan In currently implementation there will be a memory leak when nbd_client_connect() returns error status. Here is an easy way to reproduce: 1. run qemu-iotests as follow and check the result with asan: ./check -raw 143 Following is the asan output backtrack: Direct leak of

[PATCH v4 0/2] block/nbd: fix memory leak in nbd_open

From: Pan Nengyuan This series add a new function to do the common cleanups, and fix a memory leak in nbd_open when nbd_client_connect returns error status. --- Changes v2 to v1: - add a new function to do the common cleanups (suggested by Stefano Garzarella). --- Changes v3 to v2: - split in t

[PATCH v2 2/3] virtio-balloon: fix memory leak while attach virtio-balloon device

From: Pan Nengyuan ivq/dvq/svq/free_page_vq is forgot to cleanup in virtio_balloon_device_unrealize, the memory leak stack is as follow: Direct leak of 14336 byte(s) in 2 object(s) allocated from: #0 0x7f99fd9d8560 in calloc (/usr/lib64/libasan.so.3+0xc7560) #1 0x7f99fcb20015 in g_malloc

[PATCH v2 1/3] virtio: add ability to delete vq through a pointer

From: Pan Nengyuan Devices tend to maintain vq pointers, allow deleting them trough a vq pointer. Signed-off-by: Michael S. Tsirkin Signed-off-by: Pan Nengyuan --- Changes v2 to v1: - add a new function virtio_delete_queue to cleanup vq through a vq pointer --- hw/virtio/virtio.c | 16

[PATCH v2 3/3] virtio-serial-bus: fix memory leak while attach virtio-serial-bus

From: Pan Nengyuan ivqs/ovqs/c_ivq/c_ovq is forgot to cleanup in virtio_serial_device_unrealize, the memory leak stack is as bellow: Direct leak of 1290240 byte(s) in 180 object(s) allocated from: #0 0x7fc9bfc27560 in calloc (/usr/lib64/libasan.so.3+0xc7560) #1 0x7fc9bed6f015 in g_malloc

Re: for 4.2 ??? Re: [PATCH V3 2/2] block/nbd: fix memory leak in nbd_open()

t qemu.  So I'm fine if > this is deferred to 5.0, and just cc's qemu-stable (now done). > > I'll queue this through my NBD tree for 5.0. > >> >> >> 29.11.2019 10:25, pannengy...@huawei.com wrote: >>> From: PanNengyuan > >>> >>

Re: [PATCH V3 1/2] block/nbd: extract the common cleanup code

On 2019/12/4 3:00, Eric Blake wrote: > On 11/29/19 1:25 AM, pannengy...@huawei.com wrote: >> From: PanNengyuan >> >> The BDRVNBDState cleanup code is common in two places, add >> nbd_free_bdrvstate_prop() function to do these cleanups (suggested by >> Stefano

Re: [PATCH V3 1/2] block/nbd: extract the common cleanup code

I only add a change summarize in 2/2 patch in this version. should I add a summarize in 1/2 patch too if 1/2 patch is a new one? > > 29.11.2019 10:25, pannengy...@huawei.com wrote: >> From: PanNengyuan > > Strange line. Check you git preferences. Such line appears (and make

Re: [PATCH] virtio-serial-bus: fix memory leak while attach virtio-serial-bus

On 2019/12/3 16:32, Laurent Vivier wrote: > On 03/12/2019 01:53, pannengyuan wrote: >> >> >> On 2019/12/2 21:58, Laurent Vivier wrote: >>> On 02/12/2019 12:15, pannengy...@huawei.com wrote: >>>> From: PanNengyuan >>>&

Re: [PATCH] virtio-serial-bus: fix memory leak while attach virtio-serial-bus

On 2019/12/3 13:37, Michael S. Tsirkin wrote: > On Tue, Dec 03, 2019 at 08:53:42AM +0800, pannengyuan wrote: >> >> >> On 2019/12/2 21:58, Laurent Vivier wrote: >>> On 02/12/2019 12:15, pannengy...@huawei.com wrote: >>>> From: PanNengyuan >>>&

Re: [PATCH] virtio-balloon: fix memory leak while attach virtio-balloon device

On 2019/12/3 13:34, Michael S. Tsirkin wrote: > On Tue, Dec 03, 2019 at 09:44:19AM +0800, pannengy...@huawei.com wrote: >> From: PanNengyuan >> >> ivq/dvq/svq/free_page_vq is forgot to cleanup in >> virtio_balloon_device_unrealize, the memory leak stack is as follow:

[PATCH] virtio-balloon: fix memory leak while attach virtio-balloon device

From: PanNengyuan ivq/dvq/svq/free_page_vq is forgot to cleanup in virtio_balloon_device_unrealize, the memory leak stack is as follow: Direct leak of 14336 byte(s) in 2 object(s) allocated from: #0 0x7f99fd9d8560 in calloc (/usr/lib64/libasan.so.3+0xc7560) #1 0x7f99fcb20015 in

Re: [PATCH] virtio-serial-bus: fix memory leak while attach virtio-serial-bus

On 2019/12/2 21:58, Laurent Vivier wrote: > On 02/12/2019 12:15, pannengy...@huawei.com wrote: >> From: PanNengyuan >> >> ivqs/ovqs/c_ivq/c_ovq is forgot to cleanup in >> virtio_serial_device_unrealize, the memory leak stack is as bellow: >> >> Direct

[PATCH] virtio-serial-bus: fix memory leak while attach virtio-serial-bus

From: PanNengyuan ivqs/ovqs/c_ivq/c_ovq is forgot to cleanup in virtio_serial_device_unrealize, the memory leak stack is as bellow: Direct leak of 1290240 byte(s) in 180 object(s) allocated from: #0 0x7fc9bfc27560 in calloc (/usr/lib64/libasan.so.3+0xc7560) #1 0x7fc9bed6f015 in

[PATCH] virtio-input: fix memory leak in virtio_input_device_unrealize()

From: PanNengyuan vdev->vq[i] is forgot to cleanup in virtio_input_device_unrealize, the memory leak stack is as bellow: Direct leak of 3584 byte(s) in 1 object(s) allocated from: #0 0x7f84a49f6560 in calloc (/usr/lib64/libasan.so.3+0xc7560) #1 0x7f84a3b3e015 in g_malloc0 (/usr/li

[PATCH V3 1/2] block/nbd: extract the common cleanup code

From: PanNengyuan The BDRVNBDState cleanup code is common in two places, add nbd_free_bdrvstate_prop() function to do these cleanups (suggested by Stefano Garzarella). Signed-off-by: PanNengyuan --- block/nbd.c | 23 +-- 1 file changed, 13 insertions(+), 10 deletions

[PATCH V3 2/2] block/nbd: fix memory leak in nbd_open()

From: PanNengyuan In currently implementation there will be a memory leak when nbd_client_connect() returns error status. Here is an easy way to reproduce: 1. run qemu-iotests as follow and check the result with asan: ./check -raw 143 Following is the asan output backtrack: Direct leak of

Re: [PATCH V2] block/nbd: fix memory leak in nbd_open()

On 2019/11/28 21:36, Stefano Garzarella wrote: > On Thu, Nov 28, 2019 at 08:09:31PM +0800, pannengy...@huawei.com wrote: >> From: PanNengyuan >> >> In currently implementation there will be a memory leak when >> nbd_client_connect() returns error status. Here is

[PATCH V2] block/nbd: fix memory leak in nbd_open()

From: PanNengyuan In currently implementation there will be a memory leak when nbd_client_connect() returns error status. Here is an easy way to reproduce: 1. run qemu-iotests as follow and check the result with asan: ./check -raw 143 Following is the asan output backtrack: Direct leak of

Re: [PATCH] block/nbd: fix memory leak in nbd_open()

Thanks for you suggestion, I'd be glad to do it, I will send a new version later. Cheers. On 2019/11/28 18:41, Stefano Garzarella wrote: > On Thu, Nov 28, 2019 at 06:32:49PM +0800, pannengyuan wrote: >> Hi, >> I think it's a better way, you can implement this new func

Re: [PATCH] block/nbd: fix memory leak in nbd_open()

TM, but just a comment > below: > >> From: PanNengyuan >> >> In currently implementation there will be a memory leak when >> nbd_client_connect() returns error status. Here is an easy way to reproduce: >> >> 1. run qemu-iotests as follow and check the resul

[PATCH] block/nbd: fix memory leak in nbd_open()

From: PanNengyuan In currently implementation there will be a memory leak when nbd_client_connect() returns error status. Here is an easy way to reproduce: 1. run qemu-iotests as follow and check the result with asan: ./check -raw 143 Following is the asan output backtrack: Direct leak of

[PATCH V2] throttle-groups: fix memory leak in throttle_group_set_limit:

From: PanNengyuan This avoid a memory leak when qom-set is called to set throttle_group limits, here is an easy way to reproduce: 1. run qemu-iotests as follow and check the result with asan: ./check -qcow2 184 Following is the asan output backtrack: Direct leak of 912 byte(s) in 3

Re: [PATCH] throttle-groups: fix memory leak in throttle_group_set_limits

Thanks, I think it can be removed, I will send a new version later. On 2019/11/26 17:59, Alberto Garcia wrote: > On Tue 26 Nov 2019 09:17:02 AM CET, pannengy...@huawei.com wrote: >> --- a/block/throttle-groups.c >> +++ b/block/throttle-groups.c >> @@ -912,6 +912,7 @@ static void throttle_group_set

[PATCH] throttle-groups: fix memory leak in throttle_group_set_limits

From: PanNengyuan This avoid a memory leak when qom-set is called to set throttle_group limits, here is an easy way to reproduce: 1. run qemu-iotests as follow and check the result with asan: ./check -qcow2 184 Following is the asan output backtrack: Direct leak of 912 byte(s) in 3

[PATCH V2] ppc/spapr_events: fix potential NULL pointer dereference in rtas_event_log_dequeue

From: PanNengyuan This fixes coverity issues 68911917: 360 CID 68911917: (NULL_RETURNS) 361. dereference: Dereferencing "source", which is known to be "NULL". 361if (source->mask & event_mask) { 362

Re: [Qemu-devel][PATCH] ppc/spapr_events: fix potential NULL pointer dereference in rtas_event_log_dequeue

Thanks for you reply. I think you are right, I will send a new version later. On 2019/11/19 10:50, David Gibson wrote: > On Mon, Nov 18, 2019 at 09:50:13AM +0800, pannengy...@huawei.com wrote: >> From: PanNengyuan >> >> source is being dereferenced before it is null chec

[QEMU-DEVEL][PATCH] gpio: fix memory leak in aspeed_gpio_init()

From: PanNengyuan Address Sanitizer shows memory leak in hw/gpio/aspeed_gpio.c:875 Reported-by: Euler Robot Signed-off-by: PanNengyuan --- hw/gpio/aspeed_gpio.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c index 7acc5fa..41e11ea 100644

[Qemu-devel][PATCH] ppc/spapr_events: fix potential NULL pointer dereference in rtas_event_log_dequeue

From: PanNengyuan source is being dereferenced before it is null checked, hence there is a potential null pointer dereference. This fixes: 360 CID 68911917: (NULL_RETURNS) 361. dereference: Dereferencing "source", which is known to be "NULL".