From: David Rientjes <rientjes@google.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Ian Lance Taylor <iant@google.com>,
Hugh Dickins <hughd@google.com>,
Jan Stancek <jstancek@redhat.com>,
Paul McKenney <paulmck@linux.vnet.ibm.com>,
linux-mm@kvack.org
Subject: Re: [PATCH] mm: prevent mmap_cache race in find_vma()
Date: Wed, 3 Apr 2013 16:59:09 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.02.1304031648170.718@chino.kir.corp.google.com> (raw)
In-Reply-To: <20130403143302.GL1953@cmpxchg.org>
On Wed, 3 Apr 2013, Johannes Weiner wrote:
> Who cares about the implementation, we are discussing a user here.
> ACCESS_ONCE() isolates a problem so that the users don't have to think
> about it, that's the whole point of abstraction. ACCESS_ONCE() is an
> opaque building block that says it prevents the compiler from merging
> and refetching accesses. That's all we care about right now.
>
The discussion is about the implementation of ACCESS_ONCE(). Nobody, thus
far, has said anything about this specific patch other than me when I
acked it. I didn't start another thread off this patch because the
changelog is relying on the comment above ACCESS_ONCE() to say that this
"prevents the compiler from refetching." Some have been confused by this
comment and accept it at face value that it's really preventing the
compiler from doing something; in reality, it's "using gcc's
current implementation to prevent refetching." It's an important
distinction for anyone who comes away from the comment believing that
volatile-qualified pointer dereferences are forbidden to be refetched by
the compiler.
Others have said that I've somehow discouraged its use because its somehow
an invalid way of preventing gcc from refetching (when I've acked patches
that do this exact thing in slub!). I have no idea how anyone could parse
anything I've said about discouraging its use. I simply noted that the
changelog could be reworded to be clearer since we're not relying on any
standard here but rather a compiler's current implementation. It was
never intended to be a long lengthy thread, but the comment I made is
correct. I've worked with Paul to make that clearer in the comment so
that people aren't confused in the future.
--
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-03 23:59 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-02 21:59 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 [this message]
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
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
2013-04-04 18:35 Hugh Dickins
2013-04-04 18:48 ` Linus Torvalds
2013-04-04 19:01 ` Hugh Dickins
2013-04-04 19:10 ` Linus Torvalds
2013-04-04 22:30 ` Paul E. McKenney
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.1304031648170.718@chino.kir.corp.google.com \
--to=rientjes@google.com \
--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 \
/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