linux-kernel - Re: Uses for memory 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 Sep 2006 13:29:08 -0700
From:	"Paul E. McKenney" <paulmck@...ibm.com>
To:	Oliver Neukum <oliver@...kum.org>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	David Howells <dhowells@...hat.com>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Uses for memory barriers

On Mon, Sep 11, 2006 at 09:48:42PM +0200, Oliver Neukum wrote:
> Am Montag, 11. September 2006 18:21 schrieb Paul E. McKenney:
> > 1.      A given CPU will always perceive its own memory operations
> >         as occuring in program order.
> 
> Is this true for physical memory if virtually indexed caches are
> involved?

As I understand it, in systems with virtually indexed caches, the OS must
take care to ensure that a given cacheline appears only once in the cache,
even if it is mapped to multiple virtual addresses.  If an OS failed to
do this, then, as far as I can see, all bets are off.  Curt Schimmel's
book "UNIX(R) Systems for Modern Architectures: Symmetric Multiprocessing
and Caching for Kernel Programmers" is an excellent guide to the issues
posed by virtually indexed and virtually tagged caches.

In principle, one could construct a virtually indexed/tagged CPU cache 
that automatically ejected any line with a conflicting physical address
(given that lookups are presumably much more frequent than loading new
cache lines), but I have no idea if any real hardware takes this approach.
I have had the good fortune to always work with physically tagged/indexed
caches.  ;-)

						Thanx, Paul
-
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/