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 17:07:31 +0200
From:	Oliver Neukum <oliver@...kum.org>
To:	paulmck@...ibm.com
Cc:	David Howells <dhowells@...hat.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 16:55 schrieb Paul E. McKenney:
> On Tue, Sep 12, 2006 at 12:22:00PM +0200, Oliver Neukum wrote:
> > 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.
> 
> In both cases, the CPU might "discard" the write, if there are no intervening
> reads or writes to the same location.  The only difference between your

How can it know that?

> two examples is the ordering of the first store to $a and the store to $b.
> In your first example, other CPUs must see the first store to $a as happening
> first, while in your second example, other CPUs might see the store to $b
> as happening first.

There's no way in the second case a CPU might tell whether the first
write ever happened.

	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/