From: Michal Pecio <michal.pecio@gmail.com>
To: "Neronin, Niklas" <niklas.neronin@linux.intel.com>
Cc: mathias.nyman@linux.intel.com, linux-usb@vger.kernel.org,
raoxu@uniontech.com
Subject: Re: [PATCH 3/9] usb: xhci: factor out roothub bandwidth cleanup
Date: Wed, 1 Apr 2026 11:58:33 +0200 [thread overview]
Message-ID: <20260401115833.427f6f02.michal.pecio@gmail.com> (raw)
In-Reply-To: <108b65c0-349b-4854-b703-f6951b53bc33@linux.intel.com>
On Tue, 31 Mar 2026 12:34:36 +0300, Neronin, Niklas wrote:
> > This loop used to run before xhci_free_virt_devices_depth_first(),
> > but now it will run after. It seems that the endpoints here are
> > virt_ep which also should be gone already, so this loop likely does
> > nothing (empty list) or writes to virtual devices after free
> > (somebody forgot to unlink some endpoints from the list).
>
> In my testing, when xhci_rh_bw_cleanup() is called after
> xhci_free_virt_devices_depth_first() in xhci_resume(), all related
> resources have already been freed.
> That said, I have chosen to keep the existing freeing in this patch
> set. Removing it would introduce an additional behavioral change and a
> potential regression point, which I prefer to avoid at this stage.
Well, reordering these loops is also a potential behavior change.
As vdevs and tt_infos are closely tied together, I think it would make
sense for one function to free all of that stuff.
A non-behavior-changing way of doing it would be to extract the three
existing loops to such a function, in the exact order they run today.
> Do we trust xhci_free_virt_devices_depth_first() to work correctly?
> If yes then it seems this whole function is unnecessary.
I think it's correct now, in the sense that all vdevs are removed and
there is no UAF along the way. Although a few months ago an unrelated
patch did break it unexpectedly, including UAF in some edge cases.
In principle it should be possible to drop separate tt_info cleanup,
because removing vdevs achieves the same. And if it doesn't then things
would also be broken under normal operation, not only suspend, as the
same xhci_free_virt_device() is used in both situations.
Regards,
Michal
next prev parent reply other threads:[~2026-04-01 9:58 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-27 12:34 [PATCH 0/9] xhci: usb: optimize resuming from S4 (suspend-to-disk) Niklas Neronin
2026-03-27 12:34 ` [PATCH 1/9] usb: xhci: simplify CMRT initialization logic Niklas Neronin
2026-03-27 12:34 ` [PATCH 2/9] usb: xhci: relocate Restore/Controller error check Niklas Neronin
2026-03-27 12:34 ` [PATCH 3/9] usb: xhci: factor out roothub bandwidth cleanup Niklas Neronin
2026-03-30 8:29 ` Michal Pecio
2026-03-31 9:34 ` Neronin, Niklas
2026-04-01 9:58 ` Michal Pecio [this message]
2026-03-27 12:34 ` [PATCH 4/9] usb: xhci: move reserving command ring trb Niklas Neronin
2026-03-27 12:34 ` [PATCH 5/9] usb: xhci: move ring initialization Niklas Neronin
2026-03-30 8:42 ` Michal Pecio
2026-03-30 8:53 ` Neronin, Niklas
2026-04-01 9:31 ` Michal Pecio
2026-03-27 12:34 ` [PATCH 6/9] usb: xhci: move initialization for lifetime objects Niklas Neronin
2026-03-30 8:49 ` Michal Pecio
2026-03-27 12:34 ` [PATCH 7/9] usb: xhci: split core allocation and initialization Niklas Neronin
2026-03-30 8:57 ` Michal Pecio
2026-03-27 12:34 ` [PATCH 8/9] usb: xhci: improve debug messages during suspend Niklas Neronin
2026-03-30 9:14 ` Michal Pecio
2026-03-30 11:44 ` Neronin, Niklas
2026-03-27 12:34 ` [PATCH 9/9] usb: xhci: optimize resuming from S4 (suspend-to-disk) Niklas Neronin
2026-03-30 9:45 ` Michal Pecio
2026-03-31 9:59 ` Neronin, Niklas
2026-04-01 10:38 ` Michal Pecio
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=20260401115833.427f6f02.michal.pecio@gmail.com \
--to=michal.pecio@gmail.com \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
--cc=niklas.neronin@linux.intel.com \
--cc=raoxu@uniontech.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.