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
