Re: [PATCH] random: use correct memory barriers for crng_node_pool

[Paul E. McKenney]

On Mon, Sep 21, 2020 at 06:19:39PM +1000, Herbert Xu wrote:
> On Thu, Sep 17, 2020 at 09:58:02AM -0700, Eric Biggers wrote:
> >
> > smp_load_acquire() is obviously correct, whereas READ_ONCE() is an optimization
> > that is difficult to tell whether it's correct or not.  For trivial data
> > structures it's "easy" to tell.  But whenever there is a->b where b is an
> > internal implementation detail of another kernel subsystem, the use of which
> > could involve accesses to global or static data (for example, spin_lock()
> > accessing lockdep stuff), a control dependency can slip in.
> 
> If we're going to follow this line of reasoning, surely you should
> be converting the RCU derference first and foremost, no?

Agreed, rcu_dereference() is preferred over READ_ONCE() when reading
RCU-protected pointers.  Much better debugging support, if nothing else.

However, as part of making the kernel safe from DEC Alpha, READ_ONCE()
does protect against reading and dereferencing pointers to objects
concurrently being inserted into a linked data structure.  If they are
never removed (or are removed only when there are known to be no readers),
RCU is not required.

And to Eric's point, it is also true that when you have pointers to
static data, and when the compiler can guess this, you do need something
like smp_load_acquire().  But this is a problem only when you are (1)
using feedback-driven compiler optimization or (2) when you compare the
pointer to the address of the static data.

And yes, we are still working to be able to tell the compiler when
a pointer carries a dependency, but this continues to be slow going.  :-/

							Thanx, Paul