Re: [PATCH v2] USB: prevent overlapping access by usb-storage and usbfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux