[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101123050048.GL20296@one-eyed-alien.net>
Date: Mon, 22 Nov 2010 21:00:48 -0800
From: Matthew Dharm <mdharm-kernel@...-eyed-alien.net>
To: Luben Tuikov <ltuikov@...oo.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
linux-usb@...r.kernel.org, Greg KH <greg@...ah.com>,
James Bottomley <James.Bottomley@...e.de>
Subject: Re: [PATCH repost 3] [SCSI] Retrieve the Caching mode page
On Mon, Nov 22, 2010 at 12:02:26PM -0800, Luben Tuikov wrote:
> --- On Mon, 11/22/10, Linus Torvalds <torvalds@...ux-foundation.org>
> wrote:
> > So I don't mind the patch per se, but I think it's potentially way more
> > dangerous than it looks.
>
> This patch does not ask for pages that Windows doesn't ask for. The sd
> driver already asks for all pages (page code 0x3F) and then checks if the
> device is write protected. Here is the present code:
>
> 2217 sd_read_write_protect_flag(sdkp, buffer); 2218
> sd_read_cache_type(sdkp, buffer); 2219
> sd_read_app_tag_own(sdkp, buffer);
>
> Line 2217 asks for page code 0x3F, meaning all mode pages. Line 2218
> asks for the Caching mode page or not at all if the device flags forbid
> it (all USB storage devices in the Linux kernel).
>
> This patch adds processing of the data returned when all mode pages are
> asked for (0x3F) in the function on line 2218. It then parses the data to
> find out if the Caching mode page is present.
As long as you are not changing the command stream that the devices see, I
think this is a reasonable risk to take.
What are the consequences if the device returns what appear to be a Caching
Mode Page, but it is actually filled with garbage or otherwise inaccurate
data?
Matt
--
Matthew Dharm Home: mdharm-usb@...-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
You suck Stef.
-- Greg
User Friendly, 11/29/97
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists