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: <Pine.LNX.4.64.0609171919030.4388@g5.osdl.org>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ