From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: David Rientjes <rientjes@google.com>
Cc: Hugh Dickins <hughd@google.com>,
Jan Stancek <jstancek@redhat.com>,
Ian Lance Taylor <iant@google.com>,
linux-mm@kvack.org
Subject: Re: [PATCH] mm: prevent mmap_cache race in find_vma()
Date: Tue, 2 Apr 2013 20:19:02 -0700 [thread overview]
Message-ID: <20130403031902.GM3804@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1304021643260.3217@chino.kir.corp.google.com>
On Tue, Apr 02, 2013 at 04:55:45PM -0700, David Rientjes wrote:
> On Tue, 2 Apr 2013, Hugh Dickins wrote:
>
> > > > find_vma() can be called by multiple threads with read lock
> > > > held on mm->mmap_sem and any of them can update mm->mmap_cache.
> > > > Prevent compiler from re-fetching mm->mmap_cache, because other
> > > > readers could update it in the meantime:
> > >
> > > FWIW, ACCESS_ONCE() does not guarantee that the compiler will not refetch
> > > mm->mmap_cache whatsoever; there is nothing that prevents this either in
> > > the C standard. You'll be relying solely on gcc's implementation of how
> > > it dereferences volatile-qualified pointers.
> >
> > Jan is using ACCESS_ONCE() as it should be used, for its intended
> > purpose. If the kernel's implementation of ACCESS_ONCE() is deficient,
> > then we should fix that, not discourage its use.
> >
>
> My comment is about the changelog, quoted above, saying "prevent compiler
> from re-fetching mm->mmap_cache..." ACCESS_ONCE(), as implemented, does
> not prevent the compiler from re-fetching anything. It is entirely
> plausible that in gcc's current implementation that this guarantee is
> made, but it is not prevented by the language standard and I think the
> changelog should be reworded for anybody who reads it in the future.
> There is a dependency here on gcc's implementation, it's a meaningful
> distinction.
>
> I never discouraged its use since for gcc's current implementation it
> appears to work as desired and without gcc extensions there is no way to
> make such a guarantee by the standard. In fact, I acked a patch from Eric
> Dumazet that fixes a NULL pointer dereference by using ACCESS_ONCE() with
> gcc in slub.
This LWN comment from user "nix" is helpful here:
https://lwn.net/Articles/509731/
In particular:
... volatile's meaning as 'minimize optimizations applied to
things manipulating anything of volatile type, do not duplicate,
elide, move, fold, spindle or mutilate' is of long standing.
So although I agree that the standard does not say as much as one might
like about volatile, ACCESS_ONCE()'s use of volatile should be expected
to work in a wide range of C compilers. ACCESS_ONCE()'s use of typeof()
might not be quite so generally applicable, but a fair range of C
compilers do seem to support typeof() as well as ACCESS_ONCE()'s use
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>
next prev parent reply other threads:[~2013-04-03 3:19 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 [this message]
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
2013-04-03 22:28 ` Ian Lance Taylor
2013-04-12 18:05 ` Paul E. McKenney
2013-04-03 9:37 ` Jakub Jelinek
-- strict thread matches above, loose matches on Subject: below --
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=20130403031902.GM3804@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--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.