From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: 胡连勤 <hulianqin@vivo.com>, "Michal Pecio" <michal.pecio@gmail.com>
Cc: Selvarasu Ganesan <selvarasu.g@samsung.com>,
Mathias Nyman <mathias.nyman@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"quic_wcheng@quicinc.com" <quic_wcheng@quicinc.com>,
"broonie@kernel.org" <broonie@kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"cpgs@samsung.com" <cpgs@samsung.com>,
"alim.akhtar@samsung.com" <alim.akhtar@samsung.com>,
"thiagu.r@samsung.com" <thiagu.r@samsung.com>,
Niklas Neronin <niklas.neronin@linux.intel.com>
Subject: Re: 答复: 答复: [PATCH] xhci: sideband: check vdev liveness before removing endpoints on unregister
Date: Tue, 6 Oct 2026 22:07:54 +0300 [thread overview]
Message-ID: <5a9d577d-12c3-45dc-ba7d-6a4dd6326673@linux.intel.com> (raw)
In-Reply-To: <TYUPR06MB6217188F67BFDD41E4917856D2892@TYUPR06MB6217.apcprd06.prod.outlook.com>
On 10/2/26 13:12, 胡连勤 wrote:
> Hi Mathias,
>
>>> Sounds good, call xhci_sideband_remove_endpoint() for every offloaded endpoint.
>>> If possible then maybe even unregister sideband for this device completely here.
>>>
>>>
>>>> 2. Add a sideband callback in xhci_free_virt_device() for defense
>>>> in depth.
>>>
>>> Selvarasu Ganesan pointed out that xhci 'core' in fact doesn't include
>>> xhci-sideband.h yet. If possible I'd like to keep it that way.
>>>
>>> Setting xhci->sideband->vdev to NULL, or calling a callback here changes this
>>> and is the first time we then intertwine xhci core with sideband.
>>>
>>> Long term solution is to not reallocate vdev just because we try to disable and
>>> re-enable the slot to recover from a failed address device command.
>>> Usb core doesn't free and reallocate udev during device reset either.
>>>
>>> Niklas just started looking at decoupling vdev allocation and initalization.
>>> Meanwhile we could try a bandaid like:
>>>
>>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
>>> index a9e47e178c28..0b5152a1a301 100644
>>> --- a/drivers/usb/host/xhci.c
>>> +++ b/drivers/usb/host/xhci.c
>>> @@ -4435,11 +4435,15 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct usb_device *udev,
>>> dev_warn(&udev->dev, "Device not responding to setup %s.\n", act);
>>>
>>> mutex_unlock(&xhci->mutex);
>>> - ret = xhci_disable_and_free_slot(xhci, udev->slot_id);
>>> - if (!ret) {
>>> - if (xhci_alloc_dev(hcd, udev) == 1)
>>> - xhci_setup_addressable_virt_dev(xhci, udev);
>>> +
>>> + if (!virt_dev->sideband) {
>>> + ret = xhci_disable_and_free_slot(xhci, udev->slot_id);
>>> + if (!ret) {
>>> + if (xhci_alloc_dev(hcd, udev) == 1)
>>> + xhci_setup_addressable_virt_dev(xhci, udev);
>>> + }
>>> }
>>> +
>>> kfree(command->completion);
>>> kfree(command);
>>> return -EPROTO;
>>>
>>> Does this work in your case?
>>> Can you see any negative side-effects with this solution like never re-enumerating and
>>> recovering after a failed address device command?
>>>
>>
>> Thanks for the bandaid. Based on my analysis of the crash path, it
>> should work — skipping xhci_disable_and_free_slot() when sideband
>> is set keeps vdev valid, so the subsequent
>> xhci_sideband_unregister() in the disconnect path won't
>> dereference freed memory. The eventual xhci_free_dev() →
>> xhci_free_virt_device() still cleans up correctly since vdev
>> remains intact.
>>
>> I don't see obvious negative side-effects. The slot stays enabled
>> for retries, but xhci_setup_device() handles the re-address case
>> at xhci.c:4391. For truly broken devices, re_enumerate →
>> disconnect still works since vdev is valid.
>>
>> I'll apply your patch and test it with the crash scenario. Will
>> report back with the results.
>>
> Thank you for the bandaid patch. I tested it and confirmed it resolves
> the crash. The use-after-free no longer occurs when sideband is set.
>
> While discussing this with Wesley Cheng (Qualcomm), he noticed that
> there's another path that could potentially hit the same issue. The
> key difference is how pre_reset() gets invoked:
>
> - usb_reset_device() calls usb_pre_reset(), which invokes the interface
> driver's pre_reset() callback. If pre_reset() returns 1, the
> interface is force-unbound, which triggers the class driver's
> disconnect handler (e.g., uaudio_disconnect() ->
> xhci_sideband_unregister()). This unregisters the sideband and
> releases its references to vdev/out_ctx BEFORE xhci_setup_device()
> is called. So when COMP_USB_TRANSACTION_ERROR later frees
> vdev/out_ctx, there are no stale sideband references -- no crash.
>
> - finish_port_resume() calls usb_reset_and_verify_device(), which does
> NOT call usb_pre_reset(). The interface remains bound and the
> sideband is still registered, still holding references to
> vdev/out_ctx. If xhci_setup_device() then hits
> COMP_USB_TRANSACTION_ERROR and frees vdev/out_ctx, the subsequent
> usb_disconnect() -> uaudio_disconnect() ->
> xhci_sideband_unregister() -> xhci_stop_endpoint_sync() ->
> xhci_get_ep_ctx() tries to dereference the already-freed out_ctx --
> crash.
>
> Wesley suggested an alternative condition that would cover both paths:
>
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index a9e47e178c28..ff7c29b798fd 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -4435,10 +4435,12 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct usb_device *udev,
> dev_warn(&udev->dev, "Device not responding to setup %s.\n", act);
>
> mutex_unlock(&xhci->mutex);
> - ret = xhci_disable_and_free_slot(xhci, udev->slot_id);
> - if (!ret) {
> - if (xhci_alloc_dev(hcd, udev) == 1)
> - xhci_setup_addressable_virt_dev(xhci, udev);
> + if (!udev->reset_resume && !udev->reset_in_progress) {
> + ret = xhci_disable_and_free_slot(xhci, udev->slot_id);
> + if (!ret) {
> + if (xhci_alloc_dev(hcd, udev) == 1)
> + xhci_setup_addressable_virt_dev(xhci, udev);
> + }
> }
> kfree(command->completion);
> kfree(command);
>
> Instead of checking !virt_dev->sideband, this checks
> !udev->reset_resume && !udev->reset_in_progress, which covers both
> usb_reset_device() and finish_port_resume() paths for all devices.
>
> Both approaches work in our testing. We'd appreciate your guidance on
> which approach to take as the final fix.
I'd probably still go with !virt_dev->sideband
!udev->reset_resume && !udev->reset_in_progress will prevent recovery of 'address
device' failure of ordinary, non-sideband usb devices that need to be reset at resume.
Thanks
Mathias
next prev parent reply other threads:[~2026-10-06 19:08 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 12:24 [PATCH] xhci: sideband: check vdev liveness before removing endpoints on unregister 胡连勤
2026-09-10 9:34 ` Mathias Nyman
2026-09-10 11:10 ` Selvarasu Ganesan
2026-09-10 12:11 ` 答复: " 胡连勤
2026-09-10 13:50 ` Mathias Nyman
2026-09-11 5:10 ` Selvarasu Ganesan
2026-09-11 7:29 ` 答复: " 胡连勤
2026-09-11 8:41 ` Selvarasu Ganesan
2026-09-11 13:10 ` Mathias Nyman
2026-09-11 14:49 ` 答复: " 胡连勤
2026-09-12 12:18 ` Michal Pecio
2026-09-14 7:04 ` 答复: " 胡连勤
2026-09-14 9:09 ` Michal Pecio
2026-09-14 12:24 ` 答复: " 胡连勤
2026-09-14 13:09 ` Mathias Nyman
2026-09-14 14:06 ` Mathias Nyman
2026-09-14 15:34 ` Michal Pecio
2026-09-15 2:57 ` 答复: 答复: " 胡连勤
2026-10-02 10:12 ` 胡连勤
2026-10-06 19:07 ` Mathias Nyman [this message]
2026-10-08 3:23 ` 答复: " 胡连勤
2026-09-14 12:26 ` Mathias Nyman
2026-09-14 13:00 ` 答复: " 胡连勤
2026-09-14 13:40 ` Mathias Nyman
2026-09-15 3:26 ` 答复: " 胡连勤
2026-09-14 13:46 ` Michal Pecio
2026-09-15 7:45 ` 答复: " 胡连勤
2026-09-15 8:01 ` Michal Pecio
2026-09-15 8:35 ` 答复: " 胡连勤
2026-09-15 9:38 ` Michal Pecio
2026-09-15 10:11 ` 答复: " 胡连勤
2026-09-21 21:50 ` Wesley Cheng
2026-09-22 3:40 ` 答复: " 胡连勤
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=5a9d577d-12c3-45dc-ba7d-6a4dd6326673@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=alim.akhtar@samsung.com \
--cc=broonie@kernel.org \
--cc=cpgs@samsung.com \
--cc=gregkh@linuxfoundation.org \
--cc=hulianqin@vivo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=michal.pecio@gmail.com \
--cc=niklas.neronin@linux.intel.com \
--cc=quic_wcheng@quicinc.com \
--cc=selvarasu.g@samsung.com \
--cc=thiagu.r@samsung.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.