Re: [PATCH v4 2/8] rcu: clear defer_qs_pending when notifying GP changes

[Joel Fernandes <joelagnelf@nvidia.com>]

Hi Paul,

On 7/15/2026 4:45 PM, Paul E. McKenney wrote:
> On Thu, Jun 25, 2026 at 08:42:55PM -0400, Joel Fernandes wrote:
>> Prior to this commit, defer_qs_pending was an unbalanced flag:
>> rcu_read_unlock_special() set it to PENDING whenever a deferred-QS
>> mechanism was scheduled, but the clear paths did not cover every
>> up-tree quiescent-state reporting site. In those cases the flag stays
>> PENDING after the QS is reported, and rcu_read_unlock_special()'s
>> pending-gate then silently rejects all future arming attempts.
>>
>> A test patch confirms TREE03 can have get into the problematic stuck
>> state very quickly (< 5 minutes).
>>
>> Clear the flag in __note_gp_changes(), right after the nothing-to-do
>> early return.  This is the natural per-CPU "GP transitioned, sync local
>> state" hook, called from the GP-kthread's rcu_gp_init()/rcu_gp_cleanup()
>> paths, and other GP advancement paths.
>>
>> For dynticks-idle CPUs, they do not call __note_gp_changes(), but they
>> also do not arm new PENDING work (no readers running), and on wake-up,
>> note_gp_changes() is called before any new reader runs.
>>
>> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> 
> This looks plausible, but suppose we have the following:
> 
> 	rcu_read_lock();
> 	// expedited GP plus preemption.
> 	preempt_disable();
> 	rcu_read_unlock(); // Sets ->defer_qs_pending
> 	// CPU takes unrelated interrupt, softirq handled, kicks
> 	// scheduler, and clears ->defer_qs_pending. Note that preemption
> 	// is disabled, so rcu_core() does set_need_resched_current()
> 	local_irq_disable();
> 	preempt_enable(); // Cannot reschedule here.
> 	local_irq_enable();
> 
> When do quiescent states get reported?
In the regular paths? That is eventually a scheduling clock interrupt,
transition to idle, or context switch. This patch doesn't handle the above
scenario, that would be done by the timer patch.

This patch handles the case where if the ->defer_qs_pending flag was not
cleared, then it remains stuck forever.

In this patch series, we avoid clearing it once the deferred work runs,
since we don't want to re-run it to reduce/eliminate recursion risk. The
only case where we'd allow to re-run in the same GP (by clearing this flag)
it, is if it ran but did not do any work. So the idea of this patch is,
making __note_gp_changes() as the single point of clearing.

That's why "rcu: drop redundant defer_qs_pending clear in irqrestore
handler" is subsequently added later (it depends on this patch).

Thanks.