linux-kernel - Re: [PATCH] fs: Safe rcu access to hlist.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 20 Nov 2017 13:21:07 -0800
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Luc Van Oostenryck <luc.vanoostenryck@...il.com>
Cc:     Matthew Wilcox <willy@...radead.org>,
        Tim Hansen <devtimhansen@...il.com>,
        Al Viro <viro@...IV.linux.org.uk>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        alexander.levin@....verizon.com
Subject: Re: [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