On Tue, 12 Mar 2013, Ming Lei wrote: > > In general it isn't, no. But usbfs uses the lock to prevent races with > > driver_disconnect() -- it is invalid to submit URBs after the > > disconnect routine has returned. > > If so, we may introduce another lock to avoid the race. > > So I think we may figure out to decrease the device lock > scope in devio.c, and most of ioctl commands might not require it > at all, then the problem addressed by the patch can be fixed too.
That might work. A mutex could be added to the dev_state structure. The mutex would be locked whenever an URB was being submitted and during driver_disconnect, and perhaps a few other places too, but not when memory was being allocated. The device itself would remain unlocked most of the time. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
