Re: [PATCH -next v1 10/16] rcu-tasks: Document that RCU Tasks Trace grace periods now imply RCU grace periods

[Frederic Weisbecker <frederic@kernel.org>]

Le Tue, Mar 17, 2026 at 05:22:11PM -0400, Joel Fernandes a écrit :
> From: "Paul E. McKenney" <paulmck@kernel.org>
> 
> Now that RCU Tasks Trace is implemented in terms of SRCU-fast, the fact
> that each SRCU-fast grace period implies at least two RCU grace periods

two or one?

AFAIU srcu_readers_active_idx_check() it's only one?

> in turn means that each RCU Tasks Trace grace period implies at least
> two grace periods.  This commit therefore updates the documentation
> accordingly.
> 
> Reported-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
>  Documentation/RCU/Design/Requirements/Requirements.rst | 7 +++++++
>  include/linux/rcupdate.h                               | 9 +++------
>  2 files changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst
> index b5cdbba3ec2e..4d886e7c7a95 100644
> --- a/Documentation/RCU/Design/Requirements/Requirements.rst
> +++ b/Documentation/RCU/Design/Requirements/Requirements.rst
> @@ -2787,6 +2787,13 @@ which avoids the read-side memory barriers, at least for architectures
>  that apply noinstr to kernel entry/exit code (or that build with
>  ``CONFIG_TASKS_TRACE_RCU_NO_MB=y``.
>  
> +Now that the implementation is based on SRCU-fast, a call
> +to synchronize_rcu_tasks_trace() implies at least one call to
> +synchronize_rcu(), that is, every Tasks Trace RCU grace period contains
> +at least one plain vanilla RCU grace period.  Should there ever
> +be a synchronize_rcu_tasks_trace_expedited(), this guarantee would
> +*not* necessarily apply to this hypothetical API member.
> +
>  The tasks-trace-RCU API is also reasonably compact,
>  consisting of rcu_read_lock_trace(), rcu_read_unlock_trace(),
>  rcu_read_lock_trace_held(), call_rcu_tasks_trace(),
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index 04f3f86a4145..18a85c30fd4f 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -208,12 +208,9 @@ static inline void exit_tasks_rcu_finish(void) { }
>  /**
>   * rcu_trace_implies_rcu_gp - does an RCU Tasks Trace grace period imply an RCU grace period?
>   *
> - * As an accident of implementation, an RCU Tasks Trace grace period also
> - * acts as an RCU grace period.  However, this could change at any time.
> - * Code relying on this accident must call this function to verify that
> - * this accident is still happening.
> - *
> - * You have been warned!
> + * Now that RCU Tasks Trace is implemented in terms of SRCU-fast, a
> + * call to synchronize_rcu_tasks_trace() is guaranteed to imply at least
> + * one call to synchronize_rcu().
>   */
>  static inline bool rcu_trace_implies_rcu_gp(void) { return true; }

I guess the plan is to remote that function?

Other than that:

Reviewed-by: Frederic Weisbecker <frederic@kernel.org>


>  
> -- 
> 2.34.1
> 

-- 
Frederic Weisbecker
SUSE Labs