Re: [PATCH 5/5] usb: xhci: Rework and improve the TD matching and skipping logic

[Mathias Nyman <mathias.nyman@linux.intel.com>]

On 8/6/26 14:00, Michal Pecio wrote:
>> On Wed, 5 Aug 2026 20:39:12 +0300, Mathias Nyman wrote:
>> If the event points to a valid trb ahead of last trb in td, but
>> before the enqueue pointer, then we know hardware has passed this td
>> and we can give it back.
> 
> Actually, we don't, because of a race condition (and driver bug).
> 
> A very long TD completes with Short Packet on the first TRB.
> We give back the TD and advance ep_ring->dequeue past it (bug).
> Some event is generated later in the TD but we don't know yet.
> We queue a lot of TRBs and move enqueue into the completed TD.
> 
> We handle the event and it appears to be "before" enqueue. But
> the HW not only hasn't passed, it hasn't even begun executing
> any TD after the initially completed one.
> 
> We give them back and later get their events, or IOMMU faults.
> 

This isn't a realistic scenario.

Ring expansion needs to fail and class driver need to fill entire
ring buffer in the extremely short time between the short transfer
event mid TD, and the final completion event for the same TD.

xHC isn't really processing the rest of the TD's TRBs (no data
transfer) after a short transfer event.
A second event for that TD will likely point to the last TRB as
it has the IOC flag set, and that event will come almost instantly,
probably so close that both events are handled during one interrupt
handler call.

We would already now see severe issues if this could happen.
Queuing TRBs beyond hw dequeue on a full ring would overwrite the
cycle bit and hardware would likely just stop processing any TRBs

I do support changing the software dequeue to better match hardware
dequeue.

Thanks
Mathias