From: Ian Lance Taylor <iant@google.com>
To: Paul McKenney <paulmck@linux.vnet.ibm.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
David Rientjes <rientjes@google.com>,
Hugh Dickins <hughd@google.com>,
Jan Stancek <jstancek@redhat.com>,
linux-mm@kvack.org
Subject: Re: [PATCH] mm: prevent mmap_cache race in find_vma()
Date: Wed, 3 Apr 2013 10:47:28 -0700 [thread overview]
Message-ID: <CAKOQZ8wd24AUCN2c6p9iLFeHMpJy=jRO2xoiKkH93k=+iYQpEA@mail.gmail.com> (raw)
In-Reply-To: <20130403163348.GD28522@linux.vnet.ibm.com>
On Wed, Apr 3, 2013 at 9:33 AM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> On Wed, Apr 03, 2013 at 06:45:51AM -0700, Ian Lance Taylor wrote:
>
>> The C language standard only describes how access to
>> volatile-qualified objects behave. In this case x is (presumably) not
>> a volatile-qualifed object. The standard never defines the behaviour
>> of volatile-qualified pointers. That might seem like an oversight,
>> but it is not: using a non-volatile-qualified pointer to access a
>> volatile-qualified object is undefined behaviour.
>>
>> In short, casting a pointer to a non-volatile-qualified object to a
>> volatile-qualified pointer has no specific meaning in C. It's true
>> that most compilers will behave as you wish, but there is no
>> guarantee.
>
> But we are not using a non-volatile-qualified pointer to access a
> volatile-qualified object. We are doing the opposite. I therefore
> don't understand the relevance of your comment about undefined behavior.
That was just a digression to explain why the standard does not need
to define the behaviour of volatile-qualified pointers.
>> If using a sufficiently recent version of GCC, you can get the
>> behaviour that I think you want by using
>> __atomic_load(&x, __ATOMIC_RELAXED)
>
> If this maps to the memory_order_relaxed token defined in earlier versions
> of the C11 standard, then this absolutely does -not-, repeat -not-, work
> for ACCESS_ONCE().
Yes, I'm sorry, you are right. It will work in practice today but
you're quite right that there is no reason to think that it will work
in principle.
This need suggests that GCC needs a new builtin function to implement
the functionality that you want. Would you consider opening a request
for that at http://gcc.gnu.org/bugzilla/ ?
Ian
--
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 17:47 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
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 [this message]
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='CAKOQZ8wd24AUCN2c6p9iLFeHMpJy=jRO2xoiKkH93k=+iYQpEA@mail.gmail.com' \
--to=iant@google.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=jstancek@redhat.com \
--cc=linux-mm@kvack.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rientjes@google.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