linux-kernel - Re: USB serial regression 2.6.31.1 -> 2.6.31.2 [PATCH]

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] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.0910121012030.11420-100000@netrider.rowland.org>
Date:	Mon, 12 Oct 2009 10:27:39 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Matthew Dharm <mdharm-usb@...-eyed-alien.net>
cc:	Ben Efros <ben@...doctor.com>, fangxiaozhi <huananhu@...wei.com>,
	Greg KH <greg@...ah.com>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	USB list <linux-usb@...r.kernel.org>,
	Hugh Blemings <hugh@...mings.org>,
	Josua Dietze <digidietze@...isberghof.de>
Subject: Re: USB serial regression 2.6.31.1 -> 2.6.31.2 [PATCH]

On Mon, 12 Oct 2009, Benjamin Herrenschmidt wrote:

> BTW. I noticed that USB storage is supposed to avoid doing the reset if
> the device is multifunction.

Not "multifunction" but "multitarget" -- which means that the device is
attached to a real SCSI bus which may have more than one target.  In
such a situation it's best to avoid bus resets when possible, since
they affect all the targets.

>  I suppose that flag gets set prior to the
> "mode switch" and so the reset happens regardless... maybe we should set
> that MF flag from the quirk that sends the mode switch ?

You mean, avoid doing a reset after an auto-sense failure if the device
has other interfaces?  Maybe...  I'm not really sure.  To tell the
truth, that comment about "failure of an auto-sense is perfectly valid"  
doesn't make much sense to me.  In principle, the SCSI core would have
to issue its own REQUEST SENSE command and the end result would be the
same.

(In your case that wouldn't happen, because the device actually did
send valid sense data before sending the failure code.  The SCSI core
would see that data sitting in the buffer and believe it.  So things
would work out okay, but only by coincidence, not by design -- unless 
we wipe the buffer before returning.)

I don't know.  Maybe it really would be best not to reset after an 
auto-sense failure, ever.  I can't recall the issue coming up in any 
bug reports before.  But then what should we do after an auto-sense 
error?  It probably should be treated the same as a normal error, which 
means doing a reset.

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/