All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Ian Lance Taylor <iant@google.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 15:11:29 -0700	[thread overview]
Message-ID: <20130403221129.GL28522@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAKOQZ8wd24AUCN2c6p9iLFeHMpJy=jRO2xoiKkH93k=+iYQpEA@mail.gmail.com>

On Wed, Apr 03, 2013 at 10:47:28AM -0700, Ian Lance Taylor wrote:
> 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/ ?

How about a request for gcc to formally honor the current uses of volatile?

							Thanx, Paul

--
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-03 22:11 UTC|newest]

Thread overview: 42+ 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
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 [this message]
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:35 ` Hugh Dickins
2013-04-04 18:48 ` Linus Torvalds
2013-04-04 18:48   ` Linus Torvalds
2013-04-04 19:01   ` Hugh Dickins
2013-04-04 19:01     ` Hugh Dickins
2013-04-04 19:10     ` Linus Torvalds
2013-04-04 19:10       ` Linus Torvalds
2013-04-04 22:30     ` Paul E. McKenney
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=20130403221129.GL28522@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=iant@google.com \
    --cc=jstancek@redhat.com \
    --cc=linux-mm@kvack.org \
    --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 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.