Re: [patch] compiler: clarify ACCESS_ONCE() relies on compiler implementation

From: Linus Torvalds <torvalds@linux-foundation.org>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Ian Lance Taylor <iant@google.com>,
	Hugh Dickins <hughd@google.com>,
	Jan Stancek <jstancek@redhat.com>,
	Paul McKenney <paulmck@linux.vnet.ibm.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	linux-mm <linux-mm@kvack.org>
Subject: Re: [patch] compiler: clarify ACCESS_ONCE() relies on compiler implementation
Date: Thu, 4 Apr 2013 07:23:58 -0700	[thread overview]
Message-ID: <CA+55aFw_krUFFpocLOcvuANODoCJiF=QSUQeED9Xa_fLt3Gv1w@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1304032127070.32444@chino.kir.corp.google.com>

On Wed, Apr 3, 2013 at 11:02 PM, David Rientjes <rientjes@google.com> wrote:
>
> I'm surprised you would object to using a new builtin with well-defined
> semantics that would actually specify what ACCESS_ONCE() wants to do.

Why? We'd still have to have the volatile for old compilers, so it's
actually adding unnecessary code. It would be gcc-only, so we'd have
to protect it for other compilers too.

And it wouldn't add any advantage, since "volatile" would still work
for any quality compiler. So why do it?

If it was some *standard* feature that was specified by a real
standards body, and likely to become real in a few years, then that in
itself might be an argument. But as long as it's some random gcc
built-in that just does the same thing as a volatile access, what's
the upside? Seriously?

>         unsigned long local_foo = ACCESS_ONCE(foo);
>         unsigned long local_bar = ACCESS_ONCE(bar);
>
> I believe a "sane" compiler can load bar before foo and not be a bug,

That's bullshit. The whole definition of volatile is about being
visible as an access in the virtual machine, and having externally
visible side effects. Two volatiles cannot be re-ordered wrt each
other, and arguably with the traditional explanation for what it's all
about, you can't even re-order them wrt global memory accesses.

In fact, one sane semantic for what "volatile" means from a compiler
standpoint is to say that a volatile access aliases with all other
accesses (including other accesses to the same thing). That's one of
the saner approaches for compilers to handle volatile, since a C
compiler wants to have a notion of aliasing anyway (and C also has the
notion of type-based aliasing in general).

So no, a "sane" compiler cannot reorder the two.

An insane one could, but it is clearly against the spirit of what
"volatile" means. I believe it's against the letter too, but as
mentioned, compiler people love to quibble about what the meaning of
"is" is.

> The comment of ACCESS_ONCE() says "the compiler is also forbidden from
> reordering successive instances of ACCESS_ONCE(), but only when the
> compiler is aware of some particular ordering.  One way to make the
> compiler aware of ordering is to put the two invocations of ACCESS_ONCE()
> in different C statements."

Correct. That's the whole "sequence point thing". If there's a
sequence point in between (and if they are in separate C statements,
there is) a sane compiler cannot re-order them.

The comment is correct, you are just confused.

                   Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>