On Thu, Jun 25, 2026 at 08:42:57PM -0400, Joel Fernandes wrote:
> With __note_gp_changes() now clearing defer_qs_pending at every
> per-CPU GP advance, the per-irqrestore clear is redundant. Remove it.
Wait...
Given your patch 2/8 of this series, isn't __note_gp_changes() now
clearing ->defer_qs_pending on any new-to-this-CPU grace period start
or end? If that was a new-to-this-CPU grace period start, is that really
a one-to-once correspondence to the need for a quiescent state?
Thanx, Paul
> Effect: PENDING now stays set from arming until the next per-CPU GP
> advance, future arming attempts on the same CPU within the same GP are
> gated by the rcu_read_unlock_special().
>
> This serves both as an optimization (should not need new irq_work again
> this GP - for the compounded section case, we detect and clear it there),
> and reduces risks of recursion due to clearing too aggressively.
>
> Signed-off-by: Joel Fernandes <[email protected]>
> ---
> kernel/rcu/tree_plugin.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index 7768a40677a4..c37d8cfeb714 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -581,8 +581,6 @@ rcu_preempt_deferred_qs_irqrestore(struct task_struct *t,
> unsigned long flags)
> union rcu_special special;
>
> rdp = this_cpu_ptr(&rcu_data);
> - if (rdp->defer_qs_pending == DEFER_QS_PENDING)
> - rcu_defer_qs_clear(rdp);
>
> /*
> * If RCU core is waiting for this CPU to exit its critical section,
> --
> 2.34.1
>
