On 16.11.2021 10.22, Greg KH wrote:
On Tue, Nov 16, 2021 at 12:16:30AM +0200, Mathias Nyman wrote:
xHC hardware can only have one slot in default state with address 0 waiting for a unique address at a time, otherwise "undefined behavior may occur" according to xhci spec 5.4.3.4
The address0_mutex exists to prevent this across both xhci roothubs.
If hub_port_init() fails, it may unlock the mutex and exit with a xhci slot in default state. If the other xhci roothub calls hub_port_init() at this point we end up with two slots in default state.
Make sure the address0_mutex protects the slot default state across hub_port_init() retries, until slot is addressed or disabled.
Note, one known minor case is not fixed by this patch. If device needs to be reset during resume, but fails all hub_port_init() retries in usb_reset_and_verify_device(), then it's possible the slot is still left in default state when address0_mutex is unlocked.
Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman mathias.nyman@linux.intel.com
What commit id does this "fix"?
Looks like original cause could be: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel")
which was partially fixed in 4.7 by: feb26ac31a2a ("usb: core: hub: hub_port_init lock controller instead of bus")
And now improved by this patch
-Mathias