linux-kernel - Re: [RFC PATCH] usb: host: xhci: Release spinlock before xhci

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <8750e1e4-41fb-4fe7-b97e-9d2a26db45c6@linux.intel.com>
Date: Wed, 22 Oct 2025 15:49:22 +0300
From: Mathias Nyman <mathias.nyman@...ux.intel.com>
To: Uttkarsh Aggarwal <uttkarsh.aggarwal@....qualcomm.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Mathias Nyman <mathias.nyman@...el.com>
Cc: linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
 wesley.cheng@....qualcomm.com
Subject: Re: [RFC PATCH] usb: host: xhci: Release spinlock before
 xhci_handshake in command ring abort

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