linux-kernel - Re: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions

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: <alpine.LFD.0.999.0708202106290.30176@woody.linux-foundation.org>
Date:	Mon, 20 Aug 2007 21:15:58 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Brownell <david-b@...bell.net>
cc:	Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
	linux-usb-devel@...ts.sourceforge.net, Greg KH <gregkh@...e.de>,
	LKML <linux-kernel@...r.kernel.org>,
	"Stuart_Hayes@...l.com" <Stuart_Hayes@...l.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Daniel Exner <dex@...gonslave.de>
Subject: Re: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions

On Mon, 20 Aug 2007, David Brownell wrote:
> 
> MMF basically means the "Transaction Translating" (TT) hub had data
> for the host, but the host didn't collect it in time ... so that some
> data was lost.
> 
> Unfortunately, that's the type of fault that's especially hard to
> recover from.

Fair enough. However, it still seems particularly idiotic to
 - penalize everybody
 - mix up two totally unrelated areas (cpufreq and USB) for a bug that is 
   extremely rare and could be handled differently.

For example, if it really ends up being practically impossible to recover 
from split transaction errors, I would still suggest reverting that horrid 
commit, and then just black-listing the known-broken EHCI controllers and 
simply not *do* any split transactions on them. That way there's no 
complexity.

As far as I know, split transactions aren't required anyway, they are just 
a performance optimization.

Basically, we not only know that the commit has caused problems, it's 
fundamentally ugly, fragile, and not very maintainable, and the whole 
reason for doing it is pretty dubious.

Why not just admit that certain hardware is broken (and the vendor isn't 
worth even bothering to be polite with, since they try to screw us every 
chance they get) and cannot reliably do split transactions? Problem 
solved, no real downside, and nobody will even *notice*.

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