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: Thu, 4 Apr 2013 13:02:08 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.02.1304041254570.19501@chino.kir.corp.google.com> (raw)
In-Reply-To: <CA+55aFwVbnh1W6OGhVEi-OtM4OnGvk6+bAr8MGjCpvFuE3FLoA@mail.gmail.com>
On Thu, 4 Apr 2013, Linus Torvalds wrote:
> > I said in the previous email that you'd do this solely to rely on a
> > well-defined semantic rather than reading paragraphs of comments that
> > we're developing.
>
> What's "well-defined" about it? It's implementation-defined in both cases.
>
> IOW, why do you think "__builtin_access_once(x)" is fundamentally
> different from "(*(volatile type *)&(x))"? Both would be equally
> dependent on the compiler implementation, and I'd argue that it would
> be much nicer if gcc just automatically turned the existing volatile
> code internally into the builtin version (and then didn't even bother
> to expose that builtin), since if they are willing to do the built-in,
> they clearly acknowledge the need for this kind of behavior in the
> first place.
>
Agreed, and the gcc community can do that if they choose, and even better
if they explicitly state that they are doing this for the traditional
meaning (yet not standard defined) of volatile. For nothing else, it
would give me something to cite in the comment I proposed to you.
> See what I'm arguing? If a compiler writer is acknowledging that this
> kind of "access once with good semantics through a pointer" is needed
> and useful (and in the presense of IO and threading, a compiler writer
> that doesn't acknowledge that is a moron), then _why_ would that same
> compiler writer then argue against just doing that for volatile
> pointers?
>
Absolutely, it would be great.
This is why I wanted to clarify the comment of ACCESS_ONCE(), however,
that states it's "preventing the compiler" and "forbidding the compiler"
from doing certain things, because it doesn't. That's the whole
discussion. For someone interested in C, one of the natural places they
are going to look in the source is compiler.h, and especially when they
see this magical ACCESS_ONCE() floating around which is seemingly a cheap
memory barrier with other ACCESS_ONCE() references and I think we can do
better, as I did in my initial reply which started this thread, to say
this isn't in the standard and we're relying on gcc's implementation for
this behavior.
--
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>
next prev parent reply other threads:[~2013-04-04 20:02 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
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 [this message]
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.1304041254570.19501@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox