From: Mathias Nyman <mathias.nyman@intel.com>
To: Greg KH <gregkh@linuxfoundation.org>,
Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: uttkarsh.aggarwal@oss.qualcomm.com, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, wesley.cheng@oss.qualcomm.com
Subject: Re: [RFT PATCH v3] xhci: sideband: Fix race condition in sideband unregister
Date: Wed, 29 Oct 2025 15:52:28 +0200 [thread overview]
Message-ID: <094a2124-f6c9-4510-b7ec-8df872882a7d@intel.com> (raw)
In-Reply-To: <2025102956-daunting-roping-a987@gregkh>
On 10/29/25 14:51, Greg KH wrote:
> On Wed, Oct 29, 2025 at 02:24:35PM +0200, Mathias Nyman wrote:
>> Uttkarsh Aggarwal observed a kernel panic during sideband un-register
>> and found it was caused by a race condition between sideband unregister,
>> and creating sideband interrupters.
>> The issue occurrs when thread T1 runs uaudio_disconnect() and released
>> sb->xhci via sideband_unregister, while thread T2 simultaneously accessed
>> the now-NULL sb->xhci in xhci_sideband_create_interrupter() resulting in
>> a crash.
>>
>> Ensure new endpoints or interrupter can't be added to a sidenband after
>> xhci_sideband_unregister() cleared the existing ones, and unlocked the
>> sideband mutex.
>> Reorganize code so that mutex is only taken and released once in
>> xhci_sideband_unregister(), and clear sb->vdev while mutex is taken.
>>
>> Use mutex guards to reduce human unlock errors in code
>>
>> Refuse to add endpoints or interrupter if sb->vdev is not set.
>> sb->vdev is set when sideband is created and registered.
>>
>> Reported-by: Uttkarsh Aggarwal <uttkarsh.aggarwal@oss.qualcomm.com>
>> Closes: https://lore.kernel.org/linux-usb/20251028080043.27760-1-uttkarsh.aggarwal@oss.qualcomm.com
>> Fixes: de66754e9f80 ("xhci: sideband: add initial api to register a secondary interrupter entity")
>> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>> ---
>
> Looks good, thanks for respinning this. I don't know if it fixes the
> issue, but it looks sane :)
>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thanks for reviewing this.
I don't have the hardware to test this myself either
Thanks
Mathias
next prev parent reply other threads:[~2025-10-29 13:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-28 8:00 [PATCH] " Uttkarsh Aggarwal
2025-10-28 8:45 ` Greg Kroah-Hartman
2025-10-28 12:15 ` Mathias Nyman
2025-10-28 13:44 ` [RFT PATCH] " Mathias Nyman
2025-10-28 13:56 ` Greg KH
2025-10-28 14:59 ` Mathias Nyman
2025-10-28 16:51 ` [RFT PATCH v2] " Mathias Nyman
2025-10-29 10:14 ` Greg KH
2025-10-29 12:24 ` [RFT PATCH v3] " Mathias Nyman
2025-10-29 12:51 ` Greg KH
2025-10-29 13:52 ` Mathias Nyman [this message]
2025-11-07 6:16 ` Uttkarsh Aggarwal
2025-11-07 16:05 ` Mathias Nyman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=094a2124-f6c9-4510-b7ec-8df872882a7d@intel.com \
--to=mathias.nyman@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
--cc=uttkarsh.aggarwal@oss.qualcomm.com \
--cc=wesley.cheng@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®