linux-kernel - Re: [GIT PATCH] USB autosuspend fixes for 2.6.23-rc6

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: <20070913122647.525689c2.zaitcev@redhat.com>
Date:	Thu, 13 Sep 2007 12:26:47 -0700
From:	Pete Zaitcev <zaitcev@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Adrian Bunk <bunk@...nel.org>,
	linux-usb-devel@...ts.sourceforge.net, Greg KH <gregkh@...e.de>,
	linux-kernel@...r.kernel.org, Adrian Bunk <bunk@...sta.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Oliver Neukum <oneukum@...e.de>, zaitcev@...hat.com
Subject: Re: [GIT PATCH] USB autosuspend fixes for 2.6.23-rc6

On Thu, 13 Sep 2007 09:43:13 -0700 (PDT), Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> So why not make the 64 sector limit be the default? Get rid of the quirk: 
> we already allow people to override it in /sys if they really want to, but 
> realistically, it's probably not going to make any difference what-so-ever 
> for *any* normal load. So we seem to have a quirk that really doesn't buy 
> us anything but headache.

Well, ub does that today. And there is a measurable performance differential
with usb-storage when driving rotating discs, or so I heard.

> Other quirks worth looking at (but likely unfixable) are:
>  - US_FL_IGNORE_RESIDUE:
> 	Does this really matter? Can we not just always do the 
> 	US_FL_IGNORE_RESIDUE thing? Windows must not be doing what we're 
> 	doing.

I'm afraid this is valuable. However, a number of devices only return
garbage as residue if the transfer length is greater than 32KB. Limiting
that would trim this blacklist, I think. The vast majority of devices
work correctly in this regard, and ub checks the residue without any
blacklist.

>  - US_FL_FIX_CAPACITY: 
> 	This is a generic SCSI issue, not a USB one, and maybe there are 
> 	better solutions to it. Are we perhaps doing something wrong? Is 
> 	there some patterns we haven't seen? Why do we need this, when 
> 	presumably Windows does not?

It has something to do with the way our partition detection works. Linux
tends to rely on the reported device size. Windows reads the first block
and then goes further based on its contents. If we exterminate partitioning
code which uses the reported device size for autodetection, then this
problem will fix itself.

>  - US_FL_SINGLE_LUN:
> 	At least a few of these seem to indicate that the real problem 
> 	could be detected dynamically ("device reports Sub=ff") rather 
> 	than with a quirk. Quirks are unmaintainable (and change), but 
> 	noticing when devices return impossible values and going into a 
> 	"safe mode" is just defensive programming.

This is being worked upon. The recent change for floppies eliminated
a big number of those.

-- Pete
-
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/