Re: [RFC PATCH] usb: host: xhci: Release spinlock before xhci_handshake in command ring abort

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

On 10/22/25 13:00, Uttkarsh Aggarwal wrote:
> Currently xhci_handshake is a polling loop that waits for change of state.
> If this loop is executed while holding a spinlock with IRQs disabled, it
> can block interrupts for up to 5 seconds.
> 
> To prevent prolonged IRQ disable durations that may lead to watchdog
> timeouts, release the spinlock before invoking xhci_handshake() in
> xhci_abort_cmd_ring().
> 
> The spinlock is reacquired after the handshake to continue with controller
> halt and recovery if needed.

Is this a real issue?

It should be extremely rare that commands need to be aborted, and even
less likely that it takes five seconds to stop the command ring.

Can you take logs and traces of this (if it's reproducible).
I suspect there is some other issue that needs to be fixed.

I agree that keeping the spin lock for up to five seconds isn't a good idea, but
just unlocking before the command ring has stopped opens up new race risks.

We need to ensure that queuing a new command mid ring abortion, before ring stopped,
doesn't cause new issues, or that handling command completion events, including the
"stop command ring" event, before polling for a stopped ring works fine.

Thanks
Mathias