Ok I have isolated this to new locking in the sysfs file read code. This seems to be necessary locking as there was a chance that the values being read could be freed underneath us. Contention between usb_id and khubd (presumably) scanning the hub leads to extended waits usb_id trying to aquire the usb device semaphore. We could probabally fix this by converting the update of these values to rcu but that would require fixing all of those sharing the sysfs code, which appears to be all usb devices.
So the key question is, Is the delay on usb_id actually causing an issue here now that we are not blocking on it?
Ok I have isolated this to new locking in the sysfs file read code. This seems to be necessary locking as there was a chance that the values being read could be freed underneath us. Contention between usb_id and khubd (presumably) scanning the hub leads to extended waits usb_id trying to aquire the usb device semaphore. We could probabally fix this by converting the update of these values to rcu but that would require fixing all of those sharing the sysfs code, which appears to be all usb devices.
So the key question is, Is the delay on usb_id actually causing an issue here now that we are not blocking on it?