Re: [PATCH v4 3/5] usb: xhci: sideband: allocate sideband ring segments from a dedicated pool

[Michal Pecio <michal.pecio@gmail.com>]

On Tue, 13 Oct 2026 15:53:39 -0700, Wesley Cheng wrote:
> I guess my intention was to see if we could leverage the existing
> memory operations within xHCI as much as we could.

This means xhci-hcd needs to be aware of all the client requirements. 
Today we are adding DMA pool to allocate segments on separate pages.
But people may want more - say a client wants different segment size,
it needs to adjust the DMA pool, but also to add another patch because
xhci-hcd would try to create Link TRB at 4KB offset. Or maybe a client
needs more segments. Client allocation gives this flexibility.

To me this is the main appeal - both sides can evolve independently,
without needing to update each other when something changes.

Maybe the sg_table stuff could be replaced with something simpler.
Clients still needs to tell xhci-hcd where the segments are so they
can be mapped, but it could be a few xhci_sideband_[un]map_segment()
calls instead of constructing a table. In principle, a client could
even grow the ring dynamically, without any patches to xhci-hcd.

> The only concern I would have with having the client own all the
> memory operations/allocations is that we would need to carefully
> maintain the transitional phases between offloaded and non-offloaded
> scenarios to be handled properly.  At least in the audio offload
> case, we're only offloading data to the DSP when audio is active,
> which can be for a short duration, and we have proper checks and
> locking already within the xHCI mem/core layers.

Not sure if ring ownership changes anything here?
What sort of existing checks and locking do you want to rely on?

> Since I did take a look at the other issue that probably reminded you
> of this, without getting on to a tangent subject, it really broke
> down to two scenarios:
> 1.  reset_resume during bus resume
> 2.  usb_device_reset for recovery
> 
> In both situations there are requirements that when those
> happen/trigger, technically, the bus should be completely idle.  For
> #1, since we're coming from a bus suspend transition, there should be
> no pending URBs in flight, so if reset_resume happened, xfer rings
> aren't being utilized.  For #2, there were some changes that weren't
> properly handling the pre and post reset callbacks, leading to
> problems in that situation.  I think that series showed us that there
> are corner cases where referencing vdev could potentially be
> unreliable.  I'm going to assume this has no relationship to the
> client driver owning memory, please correct me if I'm wrong. :)

Right, ring UAF and driver data UAF are separate issues and changing
ring ownership won't magically fix driver bugs. It seems impossible to
avoid xhci-sideband keeping references to vdevs, because endpoints must
be stopped on sideband removal. So these references need to be found
and invalidated in all cases when devices are freed "prematurely".

But does this need to go outside xhci-hcd (including xhci-sideband)?
Are those callbacks into the client necessary? It seems they wouldn't
be necessary if ring memory is client-owned.

Regards,
Michal