On Fri, Jun 20, 2025 at 10:43:34AM +0200, Sebastian Andrzej Siewior wrote:

On 2025-06-18 10:21:40 [-0700], Boqun Feng wrote:

quoted

If it doesn't participate in rcu_read_unlock_special() then it may not
report a QS in time, right? For example:

	CPU 2			CPU 3
	=====
	rcu_read_lock_notrace();
				synchronize_rcu();
				// need all CPUs report a QS.
	rcu_read_unlock_notrace();
	// no rcu_read_unlock_special() so QS will only be reported next
	// time we if another RCU read-side critical section exits.

Wouldn't this be a problem?

I hope not because it is not any different from

 	CPU 2			CPU 3
 	=====                   =====
	NMI
 	rcu_read_lock();
 				synchronize_rcu();
 				// need all CPUs report a QS.
 	rcu_read_unlock();
 	// no rcu_read_unlock_special() due to in_nmi().

If the NMI happens while the CPU is in userland (say a perf event) then
the NMI returns directly to userland.
After the tracing event completes (in this case) the CPU should run into
another RCU section on its way out via context switch or the tick
interrupt.
I assume the tick interrupt is what makes the NMI case work.

Are you promising that interrupts will be always be disabled across
the whole rcu_read_lock_notrace() read-side critical section?  If so,
could we please have a lockdep_assert_irqs_disabled() call to check that?

							Thanx, Paul