On Fri, 11 Jul 2025 10:05:26 -0700
"Paul E. McKenney" <paul...@kernel.org> wrote:
> This trace point will invoke rcu_read_unlock{,_notrace}(), which will
> note that preemption is disabled. If rcutree.use_softirq is set and
> this task is blocking an expedited RCU grace period, it will directly
> invoke the non-notrace function raise_softirq_irqoff(). Otherwise,
> it will directly invoke the non-notrace function irq_work_queue_on().
Just to clarify some things; A function annotated by "notrace" simply
will not have the ftrace hook to that function, but that function may
very well have tracing triggered inside of it.
Functions with "_notrace" in its name (like preempt_disable_notrace())
should not have any tracing instrumentation (as Mathieu stated)
inside of it, so that it can be used in the tracing infrastructure.
raise_softirq_irqoff() has a tracepoint inside of it. If we have the
tracing infrastructure call that, and we happen to enable that
tracepoint, we will have:
raise_softirq_irqoff()
trace_softirq_raise()
[..]
raise_softirq_irqoff()
trace_softirq_raise()
[..]
Ad infinitum!
I'm not sure if that's what is being proposed or not, but I just wanted
to make sure everyone is aware of the above.
-- Steve
-
