Re: [PATCH] xhci: sideband: check vdev liveness before removing endpoints on unregister

[Michal Pecio <michal.pecio@gmail.com>]

On Mon, 14 Sep 2026 07:04:17 +0000, 胡连勤 wrote:
> > It doesn't cover hub_port_reset() called by port_event() for
> > SuperSpeed devices, not sure what that is and whether it's
> > dangerous. I noted that the original patch talks about hub_event(),
> > but maybe it's a mistake? 
> 
> Thanks for the analysis. A clarification on the hub_event() reference
> in my patch:
> 
> The crash trace shows hub_event() at the top because that's the actual
> crash call stack from the failing device. The full sequence is:
> 
>   hub_event()
>     -> port_event()                           [hub.c:5966]
>        -> usb_reset_device(udev)              [hub.c:5875]
>           -> usb_reset_and_verify_device()    [hub.c:6183]
>              -> hub_port_init()               [hub.c:6228]
>                 -> hcd->driver->address_device()  [hub.c:4781]
>                    -> xhci_setup_device()     <-- COMP_USB_TRANSACTION_ERROR
>                       -> xhci_disable_and_free_slot()  [xhci.c:4438]
>                          -> xhci_free_virt_device()   <-- frees vdev here  

So not a mistake and this is indeed a dangerous case. And AFAICT, in
this path udev's pre_reset() routine isn't called and therefore can't
be used to fix your issue, unless USB core is patched to call it.

But xhci_discover_or_reset_device() is called: before hub_port_init()
calls problematic hub_enable_device() / hub_address_device() functions,
it calls hub_port_reset(), which calls hcd->driver->reset_device().

But I'm not entirely sure what happens if reset fails before this call
is made and then hub_port_init() jumps to re_enumerate. The function
bails out, but sooner or later somebody will try to free this device in
some manner, I suppose, so what happens then?

Regards,
Michal