lkml.org 
[lkml]   [2017]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] fs: Safe rcu access to hlist.
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

\
 
 \ /
  Last update: 2017-11-20 22:22    [W:0.042 / U:10.588 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site