Messages in this thread | | | Date | Mon, 17 Dec 2018 11:21:55 -0500 (EST) | From | Alan Stern <> | Subject | Re: [PATCH] Prevent race condition between USB authorisation and USB discovery events |
| |
On Mon, 17 Dec 2018, Andrew Worsley wrote:
> A sysfs driven USB authorisation change can trigger a usb_set_configuration > while a hub_event worker thread is running. This can result in a USB device > being disabled just after it was configured and bringing down all the > devices and impacting hardware and user processes that were established on > top of this these interfaces. In some cases the USB disable never completed > and the whole system hung.
Can you be more specific about this? Disabling a USB device shouldn't cause these kinds of problems, regardless of whether or not the device was just configured.
> At my work I had an occasional hang due to this race condition. Roughly 1 > in 50 boots had the race occurrence and 1 in 4 of those resulted in a hang. > This patch fixed the problem and I had no problems (spurious disables > or hangs) in 750+ boots.
usb_authorize_device, usb_deauthorize_device, and hub_event all acquire the device mutex. Why should adding another mutex make any difference?
In fact there's an actual disadvantage: Making hub_event acquire a global mutex will prevent us from handling multiple hubs concurrently. Although we don't do this now, we might want to in the future.
Alan Stern
| |