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

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

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@fonseca.com.pt>
>> Link: https://lore.kernel.org/linux-usb/16f65081-5a3c-4c30-9811-9017796a3373@fonseca.com.pt/
>> Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
>> ---
>>
>> 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