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

Alan Stern
2026-04-23T14:12:17Z

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.

Error recovery for control endpoints would be tricky when an error
occurred during new device initialization and enumeration. Avoiding it
seems better.

Alan Stern