linux-kernel - Re: [RFC] MMIO accessors & barriers documentation #2

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:	Sun, 17 Sep 2006 19:24:31 -0700 (PDT)
From:	Linus Torvalds <torvalds@...l.org>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
cc:	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"David S. Miller" <davem@...emloft.net>,
	Jeff Garzik <jgarzik@...ox.com>,
	Paul Mackerras <paulus@...ba.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [RFC] MMIO accessors & barriers documentation #2

On Mon, 18 Sep 2006, Benjamin Herrenschmidt wrote:
> 
> Class 1: Ordered accessors
> --------------------------
> 
>  1- {read,write}{b,w,l,q} : MMIO accessors. Those accessors provide
> all MMIO ordering requirements. They are thus called "fully ordered".
> That is #1, #2 and #4 for writes and #1 and #3 for reads. 

Well, it's already not defined to be #4 right now on SGI boxes, and we 
have that (badly named) mmiowb() thing to enforce #4, so I think we should 
just accept that write[bwl]() it's _that_ ordered.

And on x86, we _already_ depend on "wmb()" to be a "normal write to MMIO 
write" barrier, which is technically wrong and bad. Again, thanks to 
mmiowb(), normal memory accesses and MMIO accesses have already been 
defined to not be in the same "ordering domain", so "wmb()" is technically 
wrong and may not order a regular write wrt a MMIO (because it doesn't do 
so for the other order: MMIO->spin_unlock).

So I think we should just admit that at least MMIO _stores_ are already 
not entirely ordered, and not try to strengthen the rules for the current 
setup (and just try to clarify the currently accepted semantics).

		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/