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 19:18:25 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.02.1304031902370.4709@chino.kir.corp.google.com> (raw)
In-Reply-To: <CA+55aFygozny+00y3hKAwkgg-6AWh0JpmqggmGcbraGrEhOkRg@mail.gmail.com>
On Wed, 3 Apr 2013, Linus Torvalds wrote:
> .. and my argument is that we don't care about paper standards, we
> care about QUALITY OF IMPLEMENTATION.
>
> If a compiler messes up volatile casts, the quality of implementation
> is bad. There's just no excuse.
>
I agreed, and I agreed when we had a "discussion" about the sign of a
bitfield six years ago, but the key here is that I'm talking about meaning
of the comment and not the compiler. I'm trying to clear up any
misconception that people have, and that's why it's a patch that modifies
a comment and not source.
Those misconceptions exist, like it or not. People have seen this
ACCESS_ONCE() abstraction and think they can use it to solve concurrency
issues in their own userland code with dereferences to shared objects.
> There is no sane alternative semantics to "volatile" that I can come
> up with. Seriously. What meaning could "volatile" ever have that would
> be sensible and break this?
>
> Now, I do repeat: I don't like volatile. I think it has many problems,
> and being underspecified is just one of them (the much deeper problem
> is that the C standard attaches it to the data, not to the code, and
> we then have to "fix" that by mis-using it as a cast).
>
I know you do and I know you contributed to having an entire
volatile-considered-harmful doc in the tree, which is really a lecture on
C rather than having anything specific to do with the kernel itself. So
I'm a little surpised that you wouldn't opt for being 100% explicit in one
of its rare appearances. It's easy to see you're no longer amused.
> So if some improved standard comes along, I'd happily use that. In the
> meantime, we don't have any choice, do we? Seriously, you can talk
> about paper standards until you are blue in the face, but since there
> is no sane alternative to the volatile cast, what's the point, really?
>
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?
--
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 2:18 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 [this message]
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.1304031902370.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox