Re: [PATCH] usb: host: xhci: Replace bus lock with host controller lock

[Mathias Nyman]

On 05.02.2016 17:14, Chris Bainbridge wrote:
> Running task list at fail point:

...

> Some of the functions appear to be inlined, the exact call chain is:
>
> hub_port_init
>      usb_get_device_descriptor
>          usb_get_descriptor
>              usb_control_msg
>                  usb_internal_control_msg
>                      usb_start_wait_urb
>                          usb_submit_urb / wait_for_completion_timeout / usb_kill_urb
>
> hub_port_init
>      hub_set_address
>          xhci_address_device
>              xhci_setup_device

hub_port_reset() will end up moving the corresponding xhci device slot to default state.

As hub_port_reset() is called several times in hub_port_init() It sounds reasonable
that we could end up with two threads having their xhci device slots in default state at
the same time,  which according to xhci 4.5.3 specs still is a big no no.

So both threads fail at their next task after this.
One fails to read the descriptor, and the other fails addressing the device.

Nice catch btw.

> So xhci_setup_device is entered while there is an outstanding URB on the
> other bus. Unless anyone can think of a better way to fix this I'll make
> the requested changes and resend my patch.

For what it's wort I think that this suggested controller mutex sounds like a good idea.
Should work for xhci at least.

-Mathias