linux-kernel - Re: [rfc][patch 3/3] x86: optimise barriers

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: <20071015074405.GA1875@ff.dom.local>
Date:	Mon, 15 Oct 2007 09:44:05 +0200
From:	Jarek Poplawski <jarkao2@...pl>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Helge Hafting <helge.hafting@...el.hist.no>,
	Nick Piggin <npiggin@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andi Kleen <ak@...e.de>
Subject: Re: [rfc][patch 3/3] x86: optimise barriers

On Fri, Oct 12, 2007 at 08:13:52AM -0700, Linus Torvalds wrote:
> 
> 
> On Fri, 12 Oct 2007, Jarek Poplawski wrote:
...
> So no, there's no way a software person could have afforded to say "it 
> seems to work on my setup even without the barrier". On a dual-socket 
> setup with s shared bus, that says absolutely *nothing* about the 
> behaviour of the exact same CPU when used with a multi-bus chipset. Not to 
> mention another revisions of the same CPU - much less a whole other 
> microarchitecture.

Yes, I still can't believe this, but after some more reading I start
to admit such things can happen in computer "science" too... I've
mentioned a lost performance, but as a matter of fact I've been more
concerned with the problem of truth:

From: Intel(R) 64 and IA-32 Architectures Software Developer's Manual
Volume 3A:

   "7.2.2 Memory Ordering in P6 and More Recent Processor Families
    ...
    1. Reads can be carried out speculatively and in any order.
    ..."

So, it looks to me like almost the 1-st Commandment. Some people (like
me) did believe this, others tried to check, and it was respected for
years notwithstanding nobody had ever seen such an event.

And then, a few years later, we have this:

From: Intel(R) 64 Architecture Memory Ordering White Paper

    "2 Memory ordering for write-back (WB) memory
     ...
     Intel 64 memory ordering obeys the following principles:
     1. Loads are not reordered with other loads.
     ..."

I know, technically this doesn't have to be a contradiction (for not
WB), but to me it's something like: "OK, Elvis lives and this guy is
not real Paul McCartney too" in an official CIA statement!

...
> Also, please note that we didn't even just change the barriers immediately 
> when the docs came out. I want to do it soon - still *early* in the 2.6.24 
> development cycle - exactly because bugs happen, and if somebody notices 
> something strange, we'll have more time to perhaps decide that "oops, 
> there's something bad going on, let's undo this for the real 2.6.24 
> release until we can figure out the exact pattern".

I'm still so "dazed and confused" that I can't tell this (or anything)
is right...

Thanks very much for so extensive and sound explanation,

Jarek P.

PS: Btw, I apologize Helge for not trusting her: "verification by
testing would not be trivial" words.
-
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/