From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>,
Tim Hansen <devtimhansen@gmail.com>,
Al Viro <viro@ZenIV.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
alexander.levin@one.verizon.com
Subject: Re: [PATCH] fs: Safe rcu access to hlist.
Date: Mon, 20 Nov 2017 13:21:07 -0800 [thread overview]
Message-ID: <20171120212107.GB3624@linux.vnet.ibm.com> (raw)
In-Reply-To: <20171120205801.dtqloltgfxkmfxee@ltop.local>
On Mon, Nov 20, 2017 at 09:58:02PM +0100, Luc Van Oostenryck wrote:
> On Mon, Nov 20, 2017 at 12:42:53PM -0800, Matthew Wilcox wrote:
> >
> > I disagree. The notion of whether a pointer is protected by RCU or not
> > is definitely not transient.
>
> Sure. But what about the memory it points to?
> It's just 'normal' kernel memory, there is nowhere
> something like some 'RCU memory', right?
>
> And the memory accessed through a __rcu annotated
> pointer can be legally be accessed with normal
> memory operation, because it's only the pointer that
> is concerned by the annotation?
It is the dereferencing of the pointer that is important.
For the pointer itself, once we have loaded it, we have loaded it,
and that is that.
The ordering that must be preserved is the load of the pointer against
later loads dereferencing that pointer. Now you might ask, as I once
did, "How can the later dereference possibly be reordered against the
pointer being dereferenced?" And the answer is that DEC Alpha really
did such reordering, and also that feedback-based optimizations could
potentially cause compilers to do such reordering. There is a lot
written on this topic, but Documentation/RCU/rcu_dereference.txt and
Documentation/memory-barriers.txt are reasonable places to start.
Or, for more recent but still experimental documentation, the file
Documentation/explanation.txt at https://github.com/aparri/memory-model.
In short, sparse's approach really does make sense here.
Thanx, Paul
prev parent reply other threads:[~2017-11-20 21:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-19 20:02 [PATCH] fs: Safe rcu access to hlist Tim Hansen
2017-11-19 21:28 ` Al Viro
2017-11-20 18:55 ` Tim Hansen
2017-11-20 20:01 ` Luc Van Oostenryck
2017-11-20 20:42 ` Matthew Wilcox
2017-11-20 20:58 ` Luc Van Oostenryck
2017-11-20 21:21 ` Paul E. McKenney [this message]
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=20171120212107.GB3624@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=alexander.levin@one.verizon.com \
--cc=devtimhansen@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.vanoostenryck@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
--cc=willy@infradead.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;
as well as URLs for NNTP newsgroup(s).