On Tue, Jul 15, 2025 at 03:56:06PM -0400, Mathieu Desnoyers wrote:

On 2025-07-14 12:34, Paul E. McKenney wrote:

quoted

On Fri, Jul 11, 2025 at 10:05:26AM -0700, Paul E. McKenney wrote:

quoted

On Fri, Jul 11, 2025 at 09:46:25AM -0400, Mathieu Desnoyers wrote:

[ . . . ]

quoted

quoted

AFAIU the goal here is to turn the guard(preempt_notrace)() into a
guard(rcu_notrace)() because the preempt-off critical sections don't
agree with BPF.

OK, got it, thank you!

The combination of BPF and CONFIG_PREEMPT_RT certainly has provided at
least its share of entertainment, that is for sure.  ;-)

Is there a similar issue with CONFIG_PREEMPT_LAZY, given that in that
case rcu_read_unlock() maps to preempt_enable(), which also can invoke
the scheduler?

I'll have to defer that question to someone who is more familiar than me
with the internals of CONFIG_PREEMPT_LAZY.

Thanks for your vote of confidence though! ;-)

Mathieu, we always have confidence in you!  ;-)

Building with CONFIG_PREEMPT_LAZY=y combines a quasi-preemptible kernel
with a non-preemptible RCU.  Which has rcu_read_unlock() defined as
preempt_disable().  There might need to be an rcu_read_unlock_notrace()
defined as preempt_disable_notrace(), given that __DECLARE_TRACE()
currently sees fit to use guard(preempt_notrace)().

Or am I overthinking this?

							Thanx, Paul