RE: [PATCH] xhci: Fix memory leak in xhci_kick_epctx when poweroff GuestOS

[Chenqun (kuhn)]

>-----Original Message-----
>From: Philippe Mathieu-Daudé [mailto:address@hidden]
>Sent: Friday, January 10, 2020 9:14 PM
>To: Chenqun (kuhn) <address@hidden>; qemu-
>address@hidden; address@hidden
>Cc: address@hidden; Pannengyuan <address@hidden>;
>Zhanghailiang <address@hidden>
>Subject: Re: [PATCH] xhci: Fix memory leak in xhci_kick_epctx when poweroff
>GuestOS
>
>On 1/10/20 11:58 AM, address@hidden wrote:
>> From: Chen Qun <address@hidden>
>>
>> start vm with libvirt, when GuestOS running, enter poweroff command
>> using the xhci keyboard, then ASAN shows memory leak stack：
>>
>> Direct leak of 80 byte(s) in 5 object(s) allocated from:
>>      #0 0xfffd1e6431cb in __interceptor_malloc (/lib64/libasan.so.4+0xd31cb)
>>      #1 0xfffd1e107163 in g_malloc (/lib64/libglib-2.0.so.0+0x57163)
>>      #2 0xaaad39051367 in qemu_sglist_init /qemu/dma-helpers.c:43
>>      #3 0xaaad3947c407 in pci_dma_sglist_init
>/qemu/include/hw/pci/pci.h:842
>>      #4 0xaaad3947c407 in xhci_xfer_create_sgl /qemu/hw/usb/hcd-
>xhci.c:1446
>>      #5 0xaaad3947c407 in xhci_setup_packet /qemu/hw/usb/hcd-xhci.c:1618
>>      #6 0xaaad3948625f in xhci_submit /qemu/hw/usb/hcd-xhci.c:1827
>>      #7 0xaaad3948625f in xhci_fire_transfer /qemu/hw/usb/hcd-xhci.c:1839
>>      #8 0xaaad3948625f in xhci_kick_epctx /qemu/hw/usb/hcd-xhci.c:1991
>>      #9 0xaaad3948f537 in xhci_doorbell_write /qemu/hw/usb/hcd-
>xhci.c:3158
>>      #10 0xaaad38bcbfc7 in memory_region_write_accessor
>/qemu/memory.c:483
>>      #11 0xaaad38bc654f in access_with_adjusted_size /qemu/memory.c:544
>>      #12 0xaaad38bd1877 in memory_region_dispatch_write
>/qemu/memory.c:1482
>>      #13 0xaaad38b1c77f in flatview_write_continue /qemu/exec.c:3167
>>      #14 0xaaad38b1ca83 in flatview_write /qemu/exec.c:3207
>>      #15 0xaaad38b268db in address_space_write /qemu/exec.c:3297
>>      #16 0xaaad38bf909b in kvm_cpu_exec /qemu/accel/kvm/kvm-all.c:2383
>>      #17 0xaaad38bb063f in qemu_kvm_cpu_thread_fn /qemu/cpus.c:1246
>>      #18 0xaaad39821c93 in qemu_thread_start /qemu/util/qemu-thread-
>posix.c:519
>>      #19 0xfffd1c8378bb  (/lib64/libpthread.so.0+0x78bb)
>>      #20 0xfffd1c77616b  (/lib64/libc.so.6+0xd616b)
>>
>> Reported-by: Euler Robot <address@hidden>
>> Signed-off-by: Chen Qun <address@hidden>
>> ---
>>   hw/usb/hcd-xhci.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c index
>> 80988bb305..0d3d96d05a 100644
>> --- a/hw/usb/hcd-xhci.c
>> +++ b/hw/usb/hcd-xhci.c
>> @@ -2000,6 +2000,7 @@ static void xhci_kick_epctx(XHCIEPContext *epctx,
>unsigned int streamid)
>>           if (xfer != NULL && xfer->running_retry) {
>>               DPRINTF("xhci: xfer nacked, stopping schedule\n");
>>               epctx->retry = xfer;
>> +            xhci_xfer_unmap(xfer);
>
>Shouldn't we use xhci_ep_free_xfer() instead?
>Also, it would be cleaner if you set it to NULL.
>
Hi  Philippe,
Thanks for your reply!  
But,  It  is just a sglist leak.  xhci_xfer_unmap() can free and set  it to 
NULL.
The  xhci_ep_free_xfer() did't free a sglist.  

By the way, xfer should be use for epctx->retry, we can't free it.

Thanks.
>>               break;
>>           }
>>           if (count++ > TRANSFER_LIMIT) {
>>