lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1205081240450.1479-100000@iolanthe.rowland.org>
Date:	Tue, 8 May 2012 13:03:17 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Paul Bolle <pebolle@...cali.nl>
cc:	"James E.J. Bottomley" <JBottomley@...allels.com>,
	Matthew Dharm <mdharm-usb@...-eyed-alien.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	<linux-scsi@...r.kernel.org>,
	<usb-storage@...ts.one-eyed-alien.net>,
	<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] scsi: usb-storage: hide errors for five devices

On Tue, 8 May 2012, Paul Bolle wrote:

> On Tue, 2012-05-08 at 10:02 -0400, Alan Stern wrote:
> > On Tue, 8 May 2012, Paul Bolle wrote: 
> > > 1) These patches try to hide those errors by:
> > > - downgrading one error to a notice; and
> > 
> > That's a reasonable thing to do, IMO.
> > 
> > > - setting the NO_WP_DETECT quirk for these five devices.
> > 
> > But that isn't.  These quirks are intended for devices that crash when
> > they receive the command in question.
> 
> Yes, these USB memory sticks don't crash. (They actually seem to work
> just fine, something that I perhaps should have emphasized in the commit
> descriptions.)
> 
> > They aren't meant to suppress sending commands to devices that can
> > properly reject them.
> 
> Even the sticks that hit "bad_sense" (in sd_read_cache_type(), which I
> forgot to mention in the comment descriptions)? Is that not as severe as
> it suggests?

It means that the device either doesn't support the MODE SENSE command
or it returned useless data.  As a result, we will assume it has a
write-through cache when it might not.

For memory sticks this doesn't matter.  For other devices it might be 
more important (although anything with a working cache should not hit 
this error case).

> Of course, an easy way out would be to downgrade both the "Asking for
> cache data failed" and the "No Caching mode page present" errors to
> notices. But the SCSI people might disagree with that approach.

Well, let's see what they say.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ