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

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

[Joel Fernandes]

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
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; }
 
-- 
2.34.1

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

[Frederic Weisbecker]

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

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

[Frederic Weisbecker]

Le Wed, Mar 18, 2026 at 12:04:23PM +0100, Frederic Weisbecker a écrit :
> 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?

But as Paul just told me offline, we flip the idx so it's two. Sorry for the noise.

Thanks.

-- 
Frederic Weisbecker
SUSE Labs