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]
Date:	Tue, 15 May 2012 08:35:39 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Paul Bolle <pebolle@...cali.nl>,
	"James E.J. Bottomley" <JBottomley@...allels.com>,
	Matthew Dharm <mdharm-usb@...-eyed-alien.net>,
	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, May 08, 2012 at 01:03:17PM -0400, Alan Stern wrote:
> 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.

What ever happened here, are these 3 patches acceptable, or do they need
to be reworked or something else?

thanks,

greg k-h
--
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