linux-kernel - Re: On trying to drop X86_PPRO

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: <20140311212544.27071674@alan.etchedpixels.co.uk>
Date:	Tue, 11 Mar 2014 21:25:44 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Stefani Seibold <stefani@...bold.net>,
	Andy Lutomirski <luto@...capital.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andreas Brief <Andreas.Brief@...de-schwarz.com>,
	Martin Runge <Martin.Runge@...de-schwarz.com>
Subject: Re: On trying to drop X86_PPRO_FENCE..

> (Although honestly, that whole thing is so long ago that my "dim
> memory" is very suspect, and it's possible the workaround actually
> came independently of that from Alan Cox. This all happened in
> v2.4.13-rc2 - late 2001 - and the PPro workaround came in together
> with the X86 OOSTORE code, which I *think* was Alan. Asking the gnomes
> in case they remember how it happened).

Because people were actually managing to hit both that and the "funny
area of broken memory" bug on the PPro. I think (but may be wrong) it was
an ALR 6 way that showed up the locking bug. The usual case you hit the
fencing errata on the PPro was MMIO writes to graphics cards. Several
drivers (notably the 3Dfx drivers) had special fencing workarounds for it.

OOSTORE was for the IDT WinChip which was an unrelated x86 processor
which had an interesting ability to run with slacker cache coherency. It
was a very simple minded CPU so wasn't good at speculation so you could
get *big* performance gains by putting it in out of order store mode.

It just happened that the feature and erratum looked similar so got dealt
with in the same basic way.

It's worth reading some of the other errata documents, fencing errata of
various kinds pop up in a wide range of x86 processors. It's up there
with "rep movs" for 'wtf' behaviour 8)

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