On Wed, 10 Oct 2012, Oliver Neukum wrote: > Hi, > > Ming Lei made me look. I found a scenario I don't like. > Suppose we have a device with two interfaces #1 and #0 > Let #1 be storage and #0 be vendor specific and the skeleton driver bound to > it. > > > CPU A > CPU B > > skel_read() > mutex_lock_interruptible(&dev->io_mutex) > copy_to_user(...) > page fault > schedule reading a page from interface #0
Looks like the copy_to_user() needs to go outside the scope of the io_mutex. In fact, io_mutex needs to protect only the device I/O. And not even all of that; just the places where URBs are submitted. > > > usb_stor_port_reset() > > > usb_reset_device() > > > drv->pre_reset() > > > skel_pre_reset() > > > mutex_lock(&dev->io_mutex) > > Contrary to the usual scenario you don't need writable mmap. In fact it could > happen with a scratched CD. > What do you think? usb-skeleton is way, way too complicated to serve as a good programming example. :-) Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
