Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751972Ab0KWE7N (ORCPT ); Mon, 22 Nov 2010 23:59:13 -0500 Received: from adsl-67-113-118-6.dsl.sndg02.pacbell.net ([67.113.118.6]:58826 "EHLO multivac.one-eyed-alien.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751017Ab0KWE7L (ORCPT ); Mon, 22 Nov 2010 23:59:11 -0500 Date: Mon, 22 Nov 2010 20:59:00 -0800 From: Matthew Dharm To: Douglas Gilbert Cc: Linus Torvalds , ltuikov@yahoo.com, linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, linux-usb@vger.kernel.org, Greg KH , James Bottomley Subject: Re: [PATCH repost 3] [SCSI] Retrieve the Caching mode page Message-ID: <20101123045900.GK20296@one-eyed-alien.net> Mail-Followup-To: Douglas Gilbert , Linus Torvalds , ltuikov@yahoo.com, linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, linux-usb@vger.kernel.org, Greg KH , James Bottomley References: <949636.86471.qm@web31809.mail.mud.yahoo.com> <4CEABE2E.4010609@interlog.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="enGqbSaueFq5omEL" Content-Disposition: inline In-Reply-To: <4CEABE2E.4010609@interlog.com> User-Agent: Mutt/1.4.2.3i Organization: One Eyed Alien Networks X-Copyright: (C) 2010 Matthew Dharm, all rights reserved. X-Message-Flag: Get a real e-mail client. http://www.mutt.org/ X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.12 (multivac.one-eyed-alien.net [127.0.0.1]); Mon, 22 Nov 2010 20:59:01 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3812 Lines: 96 --enGqbSaueFq5omEL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 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. >=20 > 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 --=20 Matthew Dharm Home: mdharm-usb@one-eyed-alien.= net=20 Maintainer, Linux USB Mass Storage Driver Sir, for the hundreth time, we do NOT carry 600-round boxes of belt-fed=20 suction darts! -- Salesperson to Greg User Friendly, 12/30/1997 --enGqbSaueFq5omEL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFM60oU3gL8qCooyc4RAirnAJ9EiydgakBEm8qiem9ngfrC2COMHwCeNZ0B tSbKvpLGzZ6w4HUFyO+4ksI= =esEZ -----END PGP SIGNATURE----- --enGqbSaueFq5omEL-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/