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]

Date:	Mon, 20 Aug 2007 21:48:45 -0700
From:	David Brownell <david-b@...bell.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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 Monday 20 August 2007, Linus Torvalds wrote:
> 
> 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.

Yes on #1, but on #2 ... frequency transitions are a common place
for systems to want to hiccup.  Maybe less so on PCs, but it's
hard to say that re-clocking an I/O or memory bus shouldn't affect
the peripherals using it for "realtime" (deadlines) I/O !!

My more complete response suggested maybe just vetoing cpufreq
transitions if the Broadcom chipset (or maybe it's just specific
boards?) finds itself in the awkward configuration ... penalizing
only the people we know could have trouble.

> 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.

Nope.  Linus, this is at least the second or third time you've
been wrong -- sorry.  But I wish you were right, since they're
such a PITA to cope with.  ;)

Split transactions are how the full and low speed devices bridge
to high speed busses.  Think of the TT hub as a speed converter,
buffering data and then retransmitting it at the other (slower or
faster) speed.  Some systems don't even have a full/low speed host
adapter ... they just have a high speed root hub and rely on some
external TT hubs (maybe on a mainboard) to handle the rest.

> 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*.

Well, I suggested an alternate fix that I hope Stuart will look at.
I think it achieves your goals (only impacting Broadcom systems).

- Dave

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