On 25/06/2025 10.27, Kevin Wolf wrote:
Commit bdf12f2a fixed the setter for the "loadparm" machine property, which gets a string from a visitor, passes it to s390_ipl_fmt_loadparm() and then forgot to free it. It left another instance of the same problem unfixed in the "loadparm" device property. Fix it.Signed-off-by: Kevin Wolf <kw...@redhat.com> --- hw/s390x/ccw-device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/s390x/ccw-device.c b/hw/s390x/ccw-device.c index 19c2238f76..8be1813b9e 100644 --- a/hw/s390x/ccw-device.c +++ b/hw/s390x/ccw-device.c @@ -57,7 +57,7 @@ static void ccw_device_set_loadparm(Object *obj, Visitor *v, Error **errp) { CcwDevice *dev = CCW_DEVICE(obj); - char *val; + g_autofree char *val = NULL; int index;
I was able to reproduce the leak with a command line like this: valgrind --trace-children=yes --track-origins=yes --leak-check=full \ --show-leak-kinds=definite ./qemu-system-s390x -nographic -accel kvm \ -drive if=none,file=/tmp/disk0.qcow2,format=qcow2,id=drive_image1 \ -device virtio-blk-ccw,drive="drive_image1",bootindex=0,loadparm=4 \ -device virtio-scsi-ccw And I can confirm that your patch fixes the issue, thank you! Tested-by: Thomas Huth <th...@redhat.com> I'll queue it for my next pull request.
