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

[David Rientjes <rientjes@google.com>]

On Wed, 3 Apr 2013, Linus Torvalds wrote:

> > Would you convert the definition of ACCESS_ONCE() to use the resulting
> > feature from the gcc folks that would actually guarantee it in the
> > compiler-gcc.h files?
> 
> So I wouldn't object for any other reason than the fact that it makes
> me feel like I'm helping somebody screw up "volatile", and then we
> would help cover up that serious compiler quality regression.
> 

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.  
Owell, it seems this is becoming philosophical.

> So I do repeat: what kind of messed-up compiler could *possibly* do
> the wrong thing for our current use of accessing a volatile pointer,
> and not consider that a compiler bug? Why should be support such a
> fundamentally broken agenda?
> 

This is tangential to the issue of trying to clarify the ACCESS_ONCE() 
comment, as that discussion was tangential to the patch actually being 
discussed at the time.  You answered it yourself, though, when talking 
about the difference between dereferencing a volatile pointer and 
accessing a volatile object.  You hate the quibbling, but are asking for a 
quibble.

	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, and 
this is allowed from the C99 perspective since we're not talking about an 
access of a volatile object, thus no side effect.  This is the quibbling 
neither of us want to get involved in, so why discuss it?

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."

That example is successive instances of ACCESS_ONCE() and in different C 
statements, but the compiler is not forbidden to reorder them.  Does 
anyone in the kernel do this and actually think it provides a cheap memory 
barrier?  Doubt it, but it's not a compiler bug to reorder them.

> IOW, I'm not seeing a huge upside, and I *am* seeing downsides.  Why
> should we encourage bad C implementations? If the compiler people
> understand that threading (as well as just IO accesses) do actually
> need the whole "access once" semantics, and have support for that in
> their compiler anyway, why aren't they just turning "volatile" into
> that?
> 

Nobody is encouraging gcc or any other compiler to change the semantics 
and I highly doubt anything ever would, even if we do adopt a gcc builtin.  
But I do believe, if nothing more, that it would clear up this confusion 
around the volatile in ACCESS_ONCE()'s definition.  If you'd like to do 
that with a comment instead, that'd be great.  I proposed such a comment.

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