On Thu, 27 Feb 2014, Dan Williams wrote: > > BTW, after some more thought, I decided the right way to avoid races in > > the peer assignments is to do some of the work under hub.c's > > device_state_lock. Add a "usb_" prefix to the name and share it with > > port.c. We already are guaranteed that all changes to port->child are > > protected by this lock, which is exactly what we need. > > > > I had wrapped locations that set port->child to NULL in the peer_lock, > but I'll look at just re-using the device_state_lock for that > scenario. You're right; an alternative to using device_state_lock in port.c is using peer_lock in hub.c. In fact, that would be superior; it wouldn't mean repurposing an existing lock. (Maybe change "peer_lock" to "usb_port_peer_mutex" while we're at it.) > I'm still thinking the start of a disconnect operation > should flush in-flight peering operations. Otherwise we'll need to > take a reference under the device_state_lock, but I'll give it more > thought. If hub_disconnect holds the mutex around the loop that removes the port devices, wouldn't that be enough? Especially if we also include the region where device_state_lock is held? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
