On Wed, Jan 16, 2013 at 11:42:09PM +0300, Sergei Shtylyov wrote: > Hello. > > On 01/14/2013 11:23 PM, Greg KH wrote: > > >>> Serialize usb-storage operations with usbfs and 'cat /proc/bus/usb/devices', > >>> so that they cannot disturb storage by seemingly harmless control reads. > > >>> This patch was adapted from 2.4.28 patch by Pete Zaitcev -- which I even had to > >>> reconstruct as I have never found it in its final form. That patch dates back > >>> to 2004 and it unfortunately wasn't applied to 2.6 branch in the same form back > >>> then (it was applied in another form and then immediately reverted). Despite 8+ > >>> years passing from that moment, the vendors didn't stop producing USB devices > >>> that require this patch. Two recent examples are SanDisk Cruzer Slice 8GB and > >>> Kingston DataTraveller 100 G2 32GB. In the latter case, even the enumeration > >>> fails as the INQUIRY command takes 2.8 seconds to finish, so 'udev' also comes > >>> into action with its control requests, with neither completing normally. > > >>> Signed-off-by: Sergei Shtylyov <sshtylyov@xxxxxxxxxxxxx> > >>> Cc: stable@xxxxxxxxxxxxxxx > > >> Forgot to mention the side effect of the patch: one can't submit read and > >> write URB simultaneously via USBDEVFS_BULK ioctl(). That has been dealt in 2.4 > >> by later patch by Pete, which I can try to port if needed. > > > That's not good, it would need to be part of this patch, we don't want > > to break that existing functionality. > > Hm... this looks more hairy that it seemed: there was another one patch in > 2.4, "between" those two, dividing usbfs ioctl's into exclusive (accessing a > device and grabbing the lock) and non-exclusive (not accessing the device and > not grabbing the lock) which I'm not sure is really needed. Then there is > USBDEVFS_BULK32 which wasn't present in 2.4 and needs analogous treating to > USBDEVFS_BULK I guess... Even if I have time to plough thru this mess, I won't > be able to test the resulting patch (the current version was tested by the > customer -- they didn't give us the faulty hardware)... Ok, given that this is due to really broken hardware, and the use case is quite rare, and the patch doesn't really solve the problem, I'll drop it from my queue. 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
