Re: [PATCH rcu 2/2] doc: Clarify rcu_assign_pointer() and rcu_dereference() ordering

[Frederic Weisbecker <frederic@kernel.org>]

Le Tue, Jun 04, 2024 at 03:21:55PM -0700, Paul E. McKenney a écrit :
> This commit expands on the ordering properties of rcu_assign_pointer()
> and rcu_dereference(), outlining their constraints on CPUs and compilers.
> 
> Reported-by: Rao Shoaib <rao.shoaib@oracle.com>
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> ---
>  Documentation/RCU/whatisRCU.rst | 30 +++++++++++++++++++-----------
>  1 file changed, 19 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst
> index 94838c65c7d97..d585a5490aeec 100644
> --- a/Documentation/RCU/whatisRCU.rst
> +++ b/Documentation/RCU/whatisRCU.rst
> @@ -250,21 +250,25 @@ rcu_assign_pointer()
>  ^^^^^^^^^^^^^^^^^^^^
>  	void rcu_assign_pointer(p, typeof(p) v);
>  
> -	Yes, rcu_assign_pointer() **is** implemented as a macro, though it
> -	would be cool to be able to declare a function in this manner.
> -	(Compiler experts will no doubt disagree.)
> +	Yes, rcu_assign_pointer() **is** implemented as a macro, though
> +	it would be cool to be able to declare a function in this manner.
> +	(And there has been some discussion of adding overloaded functions
> +	to the C language, so who knows?)
>  
>  	The updater uses this spatial macro to assign a new value to an
>  	RCU-protected pointer, in order to safely communicate the change
>  	in value from the updater to the reader.  This is a spatial (as
>  	opposed to temporal) macro.  It does not evaluate to an rvalue,
> -	but it does execute any memory-barrier instructions required
> -	for a given CPU architecture.  Its ordering properties are that
> -	of a store-release operation.
> -
> -	Perhaps just as important, it serves to document (1) which
> -	pointers are protected by RCU and (2) the point at which a
> -	given structure becomes accessible to other CPUs.  That said,
> +	but it does provide any compiler directives and memory-barrier
> +	instructions required for a given compile or CPU architecture.
> +	Its ordering properties are that of a store-release operation,
> +	that is, any prior loads and stores required to initialize the
> +	structure are ordered before the store that publishes the pointer
> +	to that structure.

About that, why rcu_dereference() isn't a matching load-acquire?

Thanks.