On Fri, May 17, 2024 at 05:23:03PM +0200, Frederic Weisbecker wrote:
> Comment the current understanding of barriers and locking role around
> task snapshot.
>
> Signed-off-by: Frederic Weisbecker <frederic@xxxxxxxxxx>
> ---
> kernel/rcu/tasks.h | 18 +++++++++++++++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h
> index 6a9ee35a282e..05413b37dd6e 100644
> --- a/kernel/rcu/tasks.h
> +++ b/kernel/rcu/tasks.h
> @@ -1738,9 +1738,21 @@ static void rcu_tasks_trace_pregp_step(struct list_head *hop)
> for_each_online_cpu(cpu) {
> rcu_read_lock();
> /*
> - * RQ must be locked because no ordering exists/can be relied upon
> - * between rq->curr write and subsequent read sides. This ensures that
> - * further context switching tasks will see update side pre-GP accesses.
> + * RQ lock + smp_mb__after_spinlock() before reading rq->curr serve
> + * two purposes:
> + *
> + * 1) Ordering against previous tasks accesses (though already enforced
> + * by upcoming IPIs and post-gp synchronize_rcu()).
> + *
> + * 2) Make sure not to miss latest context switch, because no ordering
> + * exists/can be relied upon between rq->curr write and subsequent read
> + * sides.
> + *
> + * 3) Make sure subsequent context switching tasks will see update side
> + * pre-GP accesses.
> + *
> + * smp_mb() after reading rq->curr doesn't play a significant role and might
> + * be considered for removal in the future.
> */
> t = cpu_curr_snapshot(cpu);
> if (rcu_tasks_trace_pertask_prep(t, true))
How about this for that comment?
// Note that cpu_curr_snapshot() picks up the target
// CPU's current task while its runqueue is locked with an
// smp_mb__after_spinlock(). This ensures that subsequent
// tasks running on that CPU will see the updater's pre-GP
// accesses. The trailng smp_mb() in cpu_curr_snapshot()
// does not currently play a role other than simplify
// that function's ordering semantics. If these simplified
// ordering semantics continue to be redundant, that smp_mb()
// might be removed.
I left out the "ordering agains previous tasks accesses" because,
as you say, this ordering is provided elsewhere.
Thoughts?
Thanx, Paul
