Re: [RFC PATCH 1/2] xhci: prevent automatic endpoint restart after stall or error

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

On 4/23/26 17:12, Alan Stern wrote:
> On Wed, Apr 22, 2026 at 11:35:42AM -0400, Alan Stern wrote:
>> On Wed, Apr 22, 2026 at 04:51:30PM +0300, Mathias Nyman wrote:
>>> On 4/22/26 08:30, Michal Pecio wrote:
>>>> On Tue, 21 Apr 2026 22:11:41 -0400, Alan Stern wrote:
>>>>> Can you confirm that it's also possible for xhci-hcd to prevent
>>>>> control endpoints from restarting when a transaction error (-EPROTO)
>>>>> occurs?  Up until usb_reset_endpoint() or a new callback?
>>>>
>>>> Doable. They halt like any other and it's SW's choice how to restart.
>>>
>>> Yes, doable.
>>>
>>> Would this be used in cases where all hope is lost and we want to reset the
>>> device, canceling all pending control URBs before restarting the ring,
>>> thus avoiding sending any extra URBs to the device just to wait for
>>> them to fail or timeout?
>>
>> That wasn't my intention.  The purpose was to avoid getting into a tight
>> loop such as in fuzzing tests with dummy-hcd.  When a device is
>> disconnected, if the class driver's completion handler immediately
>> resubmits after a -EPROTO error, and the resubmitted URB immediately
>> fails with -EPROTO status, the resulting loop can use enough of a CPU's
>> time to cause a "CPU hung" error.
>>
>> The same sort of thing can happen with real host controllers, although
>> the loop won't be quite so tight.  But if we prevent resubmitted URBs
>> from failing until the endpoint is reset or restarted, that will slow
>> down the loop a lot.  Especially with a series of increasing delays
>> between the restarts.
> 
> You know, on further thought I'm not sure the benefit is worth the
> effort.  I'll see if the tight-loop problem in dummy-hcd can be fixed by
> changing dummy-hcd.
> 

The tight loop -EPROTO return case is probably not a big issue for xhci
anyway  as both xhci driver and hardware cause some delay before giving back
an URB with EPROTO status.

xHC halts the host side of the control endpoints on transaction errors, and
driver will reset the internal endpoint and move the ring dequeue pointer past
the URB before giving the URB back with -EPROTO status.

-Mathias