On 19-01-2013 2:16, Sergei Shtylyov 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 patches by Pete Zaitcev. The initial patch of the series dates back to 2004 and it unfortunately wasn't applied to 2.6 in the same form back then (it was applied in another form and immediately reverted). Despite 8+ years passing from that moment, the vendors didn't stop producing USB devices that require this kind of 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 normally 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
Assuming Greg ever agrees to merge this,
I doubt it now. :-)
I will insist on a few changes.
[...]
Furthermore, the locking in usbfs doesn't look right. A process should be able to submit as many URBs as it wants, of whatever type, at any time.
You mean USBDEVFS_SUBMITURB ioctl()? That's indeed an issue with 2.4 patch (and mine, of course) -- it still accounts this ioctl() as exclusive and so only permits one instance of URB. I should have documented it internally as a side effect of the v1 patch but I'm not really familiar with usbfs, and so documented only what was fixed by Pete back in 2006 (USBDEVFS_BULK).
> The locking should be by file handle, not by "read" vs. "write".
You mean we still don't allow more than one URB per file handle?
Nevermind, I see that usbfs URBs still complete asynchronously...
But, assuming URBs complete asynchronously, I fail to see the issue with the current locking scheme... we lock during the time URB is submitted either way, what's the matter if we lock out other processes at this time? We don't seem to hinder the current process, it will submit another URB when the syscall returns, as usual. Am I missing something?
Alan Stern
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