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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ