Re: [PATCH repost 3] [SCSI] Retrieve the Caching mode page

[Matthew Dharm <mdharm-kernel-JGfshJpz5UybPZpvUQj5UqxOck334EZe@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 3221 bytes --]

On Mon, Nov 22, 2010 at 02:02:06PM -0500, Douglas Gilbert wrote:
> On 10-11-22 12:07 PM, Linus Torvalds wrote:
> >On Mon, Nov 22, 2010 at 8:56 AM, Luben Tuikov<ltuikov-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>  wrote:
> >>
> >>Some kernel transport drivers unconditionally disable
> >>retrieval of the Caching mode page. One such for example is
> >>the BBB/CBI transport over USB.
> >
> >One reason for that is that historically we've seen devices that
> >simply go crazy - to the point of simply stopping to respond to
> >anything - when you ask for pages that Windows doesn't ask for.
> >
> >It's especially common on USB storage, but it happens elsewhere too.
> >The device firmware simply hasn't ever been tested in that situation,
> >and it's buggy.
> >
> >So I don't mind the patch per se, but I think it's potentially way
> >more dangerous than it looks.
> 
> The vast majority of USB mass storage devices are based
> on SCSI-2 (1994) or a particularly nasty standard
> called RBC (Reduced Block Commands, 1999) which is a
> partial subset of the block commands (i.e. disk related).
> We are all aware of the quality of most of the device
> end implementations out in the wild.

Not true.  The vast majority of USB mass storage devices adhere to no SCSI
or T10 specification at all.  The official definition of the "Transparent
SCSI" operating mode of the USB Mass Storage Class is "that which
microsoft/sun/other major vendors use".  Of course, that's not written down
anywhere, but it was the intent of the committee and that is the reason why
the committee rejected all attempts by people like me to implement a
command-based compliance test.

> I believe what Luben is working with is a new standard
> called UAS (soon to be ratified) which is based on
> www.t10.org work in the last few years. It seems to be
> an attempt to throw out the older USB mass storage
> transport and do it again, properly.

Luben's patch changes the behavior of sd-mod, which would affect both
usb-storage and UAS.

The primary thing that UAS adds is support for USB 3.0 streams and TCQ,
which are both designed to improve performance.  I consider it likely that
the quality of device firmware will be equally poor as older devices.

That said, Luben's patch is kinda slick.  sd-mod already asks for a lot of
mode page data; it does this so that it's request matches the observed
behavior of a "popular" Redmond, WA-based OS.  Luben's patch just searches
through that data to see if it can find what it is looking for, rather than
rqeuesting a specific mode page later (which may not be supported).

That said, I still consider this somewhat risky.  We've seen devices with
grossly inaccurate data before.

But, to my thinking, as long as the devices don't see any change in the
command stream, then I think the risk has been properly mitigated.  To my
understanding, this is the case.

Matt

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

Sir, for the hundreth time, we do NOT carry 600-round boxes of belt-fed 
suction darts!
					-- Salesperson to Greg
User Friendly, 12/30/1997

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]