Re: [PATCH] usb: xhci: Unlock for command abort polling

[Mathias Nyman]

On 10/2/26 12:33, Michal Pecio wrote:
> On Mon, 24 Aug 2026 09:59:44 +0200, Michal Pecio wrote:
> > xhci_abort_cmd_ring() requests abort, waits for the CRR bit to clear,
> > drops xhci->lock and waits for the Command Ring Stopped event.
> >
> > The CRR wait timeout is 5 seconds as suggested by xHCI 4.6.1.2, which
> > means that if the xHC fails to complete the operation at all, we poll
> > with the lock held and IRQs disabled for several seconds. If any other
> > CPU tries to acquire the lock, it will spin likewise. IRQs get delays,
> > drivers log errors, tasks freeze, it's a mess.
> >
> > So drop the lock earlier, before waiting for the CRR bit. It should be
> > safe - the sole caller sets cmd_ring_state to CMD_RING_STATE_ABORTED
> > before calling us, which will prevent others from ringing the command
> > doorbell and interfering with the abort. Queuing new commands during
> > this time poses no danger, and if the command we try to abort actually
> > completes concurrently, existing code already needs to deal with this.
> > And in my testing it does - it's trivial to trigger this on ASM1042,
> > where Address Device can't be aborted, but it completes as soon as the
> > offending device is unplugged, including during abort attempt.
> >
> > Note that the lock still covers reinit_completion(), so it won't race
> > with complete() being called by the event handler. And works are not
> > reentrant, so another timeout can't expire while the lock is dropped.
> > We will configure timeout anew when restarting the ring.
> >
> > One other difference is that now we also drop the lock if abort fails.
> > This too should be harmless. Commands queued during this time will be
> > released like any other pending commands. If the aborted command does
> > complete before we regain the lock, it's a waste, but not regression.
> >
> > Reported-by: Pedro Fonseca <pedro@xxxxxxxxxxxxxx>
> > Link: https://lore.kernel.org/linux-usb/16f65081-5a3c-4c30-9811-9017796a3373@xxxxxxxxxxxxxx/
> > Signed-off-by: Michal Pecio <michal.pecio@xxxxxxxxx>
> > ---
> >
> > This has been annoying me and various others for years, only the latest
> > incident is listed above.
> >
> > I expected a nightmare of race conditions, but after finally taking a
> > serious look I think it really is quite simple. It helps that the lock
> > was already being dropped and existing code seems to handle it fine.
>
> Hi Mathias,
>
> Any thoughts about this one? Seems we haven't got any response from
> Pedro, but the patch worked for me (and it solves an annoying bug).

Just added this and a couple of others of your patches for my for-usb-next branch

Thanks
Mathias