Hello. On 01/17/2013 07:27 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... OK, that turned out to be a no-brainer -- both of these ioctl's are handled by proc_bulk() in the end. >> 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. There must be some misunderstanding: I was talking about the efforts recasting the patch to deal with "duplexing" USBDEVFS_BULK[32]. As is, the patch does its job, and the use case isn't at all rare, it's normal boot sequence for Kingston sticks. Also, I had an impression that you wouldn't queue it unless it's recast to deal with USBDEVFS_BULK[32], no? > thanks, > greg k-h WBR, Sergei -- 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
