All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
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: Wed, 3 Apr 2013 18:52:04 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.02.1304031812320.4709@chino.kir.corp.google.com> (raw)
In-Reply-To: <CA+55aFwdJCxnNQMQEAaC-+8pEGpHKgaq5aL4K2n=vRVBUg863A@mail.gmail.com>

On Wed, 3 Apr 2013, Linus Torvalds wrote:

> Any compiler that thinks it can load something through a "volatile"
> pointer multiple times is SHIT. We don't add these kinds of comments
> to make excuses for crap, we call out such compilers and tell people
> not to use the utter crap they are.
> 

How nice to have reconvened after six years when in February of 2007 you 
slammed me for relying on the implementation of a particular compiler on 
the sign of a bitfield and referred multiple times to the standard and how 
it's implementation defined.  I don't want to go down that road again, 
even though the poster of quotes we had on the wall at work was amusing 
for awhile.

The specification here says an access to this volatile quaified pointer is 
implementation defined.  It also allows for the pointer to be reloaded and 
the local variable optimized out.  Do people need to know that?  
Debatable.  But there are misconceptions of what a volatile-qualified 
pointer can do.

This patch was an attempt to clarify for those who didn't understand that 
we're relying on the implementation of the compiler to not optimize the 
loads from memory out.  The way the comment is currently written, stating 
that it is "preventing the compiler from refetching" can literally mean 
one of two things: it actually does something based on specification that 
causes these objects to not be reloaded, or it is using the way 
volatile-qualified pointers are dereferenced in gcc and other compilers to 
prevent it.  I'm pretty darn sure Paul was referring to the latter when he 
wrote it, which is completely 100% correct, but other readers of the 
comment have taken it to mean the former and it causes misconceptions of 
the keyword.

That said, I'm not interested in arguing with you on the meaning of the 
word "prevent" in the ACCESS_ONCE() comment nor in the changelog of the 
patch that sparked this discussion.  We're talking about English here, not 
C, and the goal was to make it explicit.  If you take offense to that, 
owell.

Ian has suggested that we file a request with the gcc team for the exact 
semantics we're asking for from ACCESS_ONCE() so that we don't need to 
rely on any particular compiler's implementation and can standardize this 
at least for gcc.

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

  reply	other threads:[~2013-04-04  1:52 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-02 21:59 [PATCH] mm: prevent mmap_cache race in find_vma() Jan Stancek
2013-04-02 22:33 ` David Rientjes
2013-04-02 23:09   ` Hugh Dickins
2013-04-02 23:55     ` David Rientjes
2013-04-03  3:19       ` Paul E. McKenney
2013-04-03  4:21         ` David Rientjes
2013-04-03 16:38           ` Paul E. McKenney
2013-04-03  4:14       ` Johannes Weiner
2013-04-03  4:25         ` David Rientjes
2013-04-03  4:58           ` Johannes Weiner
2013-04-03  5:13             ` David Rientjes
2013-04-03 13:45             ` Ian Lance Taylor
2013-04-03 14:33               ` Johannes Weiner
2013-04-03 23:59                 ` David Rientjes
2013-04-04  0:00                   ` [patch] compiler: clarify ACCESS_ONCE() relies on compiler implementation David Rientjes
2013-04-04  0:38                     ` Linus Torvalds
2013-04-04  1:52                       ` David Rientjes [this message]
2013-04-04  2:00                         ` Linus Torvalds
2013-04-04  2:18                           ` David Rientjes
2013-04-04  2:37                             ` Linus Torvalds
2013-04-04  6:02                               ` David Rientjes
2013-04-04 14:23                                 ` Linus Torvalds
2013-04-04 19:40                                   ` David Rientjes
2013-04-04 19:53                                     ` Linus Torvalds
2013-04-04 20:02                                       ` David Rientjes
2013-04-03 16:33               ` [PATCH] mm: prevent mmap_cache race in find_vma() Paul E. McKenney
2013-04-03 16:41                 ` Paul E. McKenney
2013-04-03 17:47                 ` Ian Lance Taylor
2013-04-03 22:11                   ` Paul E. McKenney
2013-04-03 22:28                     ` Ian Lance Taylor
2013-04-12 18:05                       ` Paul E. McKenney
2013-04-03  9:37   ` Jakub Jelinek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.02.1304031812320.4709@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=iant@google.com \
    --cc=jstancek@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.