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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 12 Sep 2006 12:22:00 +0200
From:	Oliver Neukum <oliver@...kum.org>
To:	David Howells <dhowells@...hat.com>
Cc:	paulmck@...ibm.com, Alan Stern <stern@...land.harvard.edu>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Uses for memory barriers

Am Dienstag, 12. September 2006 11:01 schrieb David Howells:
> Paul E. McKenney <paulmck@...ibm.com> wrote:
> 
> > 2.	All stores to a given single memory location will be perceived
> > 	as having occurred in the same order by all CPUs.
> 
> Does that take into account a CPU combining or discarding coincident memory
> operations?
> 
> For instance, a CPU asked to issue two writes to the same location may discard
> the first if it hasn't done it yet.

Does it make sense? If you do:
mov #x, $a
wmb
mov #y, $b
wmb
mov #z, $a

The CPU must not discard any write. If you do

mov #x, $a
mov #y, $b
wmb
mov #z, $a

The first store to $a is superfluous if you have only inter-CPU
issues in mind.

	Regards
		Oliver
-
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/