On Wed, Oct 10, 2012 at 11:08:11AM -0400, Alan Stern wrote: > 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. :-) I agree, it's grown way to large and complex, which makes me wonder if a "simple" USB driver is too large and complex these days and we are doing something wrong... It's on my TODO list to clean up and look at closer one of these days, luckily no one is writing new USB drivers anymore, they all just end up being some type of a class device. thanks, greg k-h -- 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
