All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Wang" <00107082@163.com>
To: "Mathias Nyman" <mathias.nyman@linux.intel.com>
Cc: "Michał Pecio" <michal.pecio@gmail.com>,
	WeitaoWang-oc@zhaoxin.com, gregkh@linuxfoundation.org,
	linux-usb@vger.kernel.org, regressions@lists.linux.dev,
	linux-kernel@vger.kernel.org, surenb@google.com,
	kent.overstreet@linux.dev
Subject: Re: [REGRESSION 6.17-rc3] usb/xhci: possible memory leak after suspend/resume cycle.
Date: Mon, 1 Sep 2025 19:17:38 +0800 (CST)	[thread overview]
Message-ID: <7e8a138e.af64.19904ff3496.Coremail.00107082@163.com> (raw)
In-Reply-To: <f9476552-a6dc-4f1c-91da-b15c8f0d9844@linux.intel.com>


At 2025-09-01 18:14:32, "Mathias Nyman" <mathias.nyman@linux.intel.com> wrote:
>On 30.8.2025 13.17, David Wang wrote:
>> 
>> At 2025-08-30 17:48:28, "Michał Pecio" <michal.pecio@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> Good work, looks like suspend/resume is a little understested corner
>>> of this driver.
>>>
>>> Did you check whether the same leak occurs if you simply disconnect
>>> a device or if it's truly unique to suspend?
>>>
>>>> And bisect narrow down to commit 2eb03376151bb8585caa23ed2673583107bb5193(
>>>> "usb: xhci: Fix slot_id resource race conflict"):
>>>
>>> I see a trivial bug which everyone (myself included tbh) missed before.
>>> Does this help?
>>>
>>> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
>>> index f11e13f9cdb4..f294032c2ad7 100644
>>> --- a/drivers/usb/host/xhci-mem.c
>>> +++ b/drivers/usb/host/xhci-mem.c
>>> @@ -932,7 +932,7 @@ void xhci_free_virt_device(struct xhci_hcd *xhci, struct xhci_virt_device *dev,
>>>   */
>>> static void xhci_free_virt_devices_depth_first(struct xhci_hcd *xhci, int slot_id)
>>> {
>>> -	struct xhci_virt_device *vdev;
>>> +	struct xhci_virt_device *vdev, *tmp_vdev;
>>> 	struct list_head *tt_list_head;
>>> 	struct xhci_tt_bw_info *tt_info, *next;
>>> 	int i;
>>> @@ -952,8 +952,8 @@ static void xhci_free_virt_devices_depth_first(struct xhci_hcd *xhci, int slot_i
>>> 		if (tt_info->slot_id == slot_id) {
>>> 			/* are any devices using this tt_info? */
>>> 			for (i = 1; i < HCS_MAX_SLOTS(xhci->hcs_params1); i++) {
>>> -				vdev = xhci->devs[i];
>>> -				if (vdev && (vdev->tt_info == tt_info))
>>> +				tmp_vdev = xhci->devs[i];
>>> +				if (tmp_vdev && (tmp_vdev->tt_info == tt_info))
>>> 					xhci_free_virt_devices_depth_first(
>>> 						xhci, i);
>> 
>> I confirmed this *silly* code is the root cause of this memory leak.
>> And I would suggest simpler code changes (which is what I was testing):
>> 
>> 
>> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
>> index 81eaad87a3d9..c4a6544aa107 100644
>> --- a/drivers/usb/host/xhci-mem.c
>> +++ b/drivers/usb/host/xhci-mem.c
>> @@ -962,7 +962,7 @@ static void xhci_free_virt_devices_depth_first(struct xhci_hcd *xhci, int slot_i
>>   out:
>>          /* we are now at a leaf device */
>>          xhci_debugfs_remove_slot(xhci, slot_id);
>> -       xhci_free_virt_device(xhci, vdev, slot_id);
>> +       xhci_free_virt_device(xhci, xhci->devs[slot_id], slot_id);
>>   }
>>   
>>   int xhci_alloc_virt_device(struct xhci_hcd *xhci, int slot_id,
>> 
>
>Thanks to both for catching this
>
>I can quickly turn this into a proper patch unless one of you would like to submit one?

Oh, I was not planning to submit a patch at all, since Michał Pecio got the credit of publishing the first patch.

Thanks
David

>
>Thanks
>Mathias

  reply	other threads:[~2025-09-01 11:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-29 18:13 [REGRESSION 6.17-rc3] usb/xhci: possible memory leak after suspend/resume cycle David Wang
2025-08-30  9:48 ` Michał Pecio
2025-08-30 10:06   ` David Wang
2025-08-30 10:17   ` David Wang
2025-09-01 10:14     ` Mathias Nyman
2025-09-01 11:17       ` David Wang [this message]
2025-09-02  7:30       ` [PATCH] usb: xhci: Fix xhci_free_virt_devices_depth_first() Michal Pecio
2025-09-02  8:30         ` David Wang
2025-09-02  8:46           ` [PATCH] " Michał Pecio
2025-09-02  9:07             ` Michał Pecio
2025-09-02 10:13               ` Mathias Nyman
2025-09-02 10:55                 ` Michał Pecio
2025-09-02 12:58                   ` Mathias Nyman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7e8a138e.af64.19904ff3496.Coremail.00107082@163.com \
    --to=00107082@163.com \
    --cc=WeitaoWang-oc@zhaoxin.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    --cc=michal.pecio@gmail.com \
    --cc=regressions@lists.linux.dev \
    --cc=surenb@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.