[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZmBSZ3AAp9TN5YaP@localhost.localdomain>
Date: Wed, 5 Jun 2024 13:56:23 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: rcu@...r.kernel.org, linux-kernel@...r.kernel.org, kernel-team@...a.com,
rostedt@...dmis.org, Rao Shoaib <rao.shoaib@...cle.com>
Subject: Re: [PATCH rcu 2/2] doc: Clarify rcu_assign_pointer() and
rcu_dereference() ordering
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@...cle.com>
> Signed-off-by: Paul E. McKenney <paulmck@...nel.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.
Powered by blists - more mailing lists