linux-kernel - Re: I/O memory barriers vs SMP 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:	Mon, 26 Mar 2007 11:04:11 +0100
From:	David Howells <dhowells@...hat.com>
To:	Lennert Buytenhek <buytenh@...tstofly.org>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Catalin Marinas <catalin.marinas@....com>,
	ARM Linux Mailing List 
	<linux-arm-kernel@...ts.arm.linux.org.uk>,
	Dan Williams <dan.j.williams@...el.com>,
	linux-kernel@...r.kernel.org, torvalds@...l.org,
	dhowells@...hat.com
Subject: Re: I/O memory barriers vs SMP memory barriers 

Lennert Buytenhek <buytenh@...tstofly.org> wrote:

> Does everybody agree on these semantics, though?  At least David seems
> to think that mb/rmb/wmb aren't required to order normal memory accesses
> against each other..

Ummm...  I've just realised that your statement here is ambiguous.  When you
say "aren't required to", do you mean "aren't necessary to" or do you mean
"don't have to"?  Isn't English a fun language?

Anyway, what I meant is that mb() and co. as they stand _must_ do everything
smp_mb() and co do respectively, _in_ _addition_ to other side effects.

	mb() implies smp_mb()
	rmb() implies smp_rmb()
	wmb() implies smp_wmb()
	...

David
-
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/