Re: [PATCH v2 10/16] tracing: Guard __DECLARE_TRACE() use of __DO_TRACE_CALL() with SRCU-fast

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 6 Nov 2025 17:04:33 -0800
"Paul E. McKenney" <paulmck@kernel.org> wrote:
> > 
> > It gets a bit more confusing. We see "migrate disabled" (the last number)
> > except when preemption is enabled.  
> 
> Huh.  Would something like "...11" indicate that both preemption and
> migration are disabled?

Preemption was disabled when coming in.

> 
> >                                    That's because in your code, we only do
> > the migrate dance when preemption is disabled:
> >   
> > > +			if (IS_ENABLED(CONFIG_PREEMPT_RT) && preemptible()) {	\  
> 
> You lost me on this one.  Wouldn't the "preemptible()" condition in that
> "if" statement mean that migration is disabled only when preemption
> is *enabled*?
> 
> What am I missing here?

So preemption is disabled when the event was hit. That would make
"preemptible()" false, and we will then up the preempt_count again and
not disable migration.

The code that records the preempt count expects the tracing code to
increment the preempt_count, so it decrements it by one. Thus it records;

  ...1.

As migrate disable wasn't set.

> 
> > > +				guard(srcu_fast_notrace)(&tracepoint_srcu);	\
> > > +				guard(migrate)();				\
> > > +				__DO_TRACE_CALL(name, TP_ARGS(args));		\
> > > +			} else {						\
> > > +				guard(preempt_notrace)();			\
> > > +				__DO_TRACE_CALL(name, TP_ARGS(args));		\
> > > +			}  
> > 
> > And that will make accounting in the trace event callback much more
> > difficult, when it's sometimes disabling migration and sometimes disabling
> > preemption. It must do one or the other. It can't be conditional like that.
> > 
> > With my update below, it goes back to normal:
> > 
> >             bash-1040    [004] d..2.    49.339890: lock_release: 000000001d24683a tasklist_lock
> >             bash-1040    [004] d..2.    49.339890: irq_enable: caller=_raw_write_unlock_irq+0x28/0x50 parent=0x0
> >             bash-1040    [004] ...1.    49.339891: lock_release: 00000000246b21a5 rcu_read_lock
> >             bash-1040    [004] .....    49.339891: lock_acquire: 0000000084e3738a read &mm->mmap_lock
> >             bash-1040    [004] .....    49.339892: lock_release: 0000000084e3738a &mm->mmap_lock
> >             bash-1040    [004] .....    49.339892: lock_acquire: 00000000f5b22878 read rcu_read_lock_trace
> >             bash-1040    [004] .....    49.339892: lock_acquire: 0000000084e3738a read &mm->mmap_lock
> >             bash-1040    [004] .....    49.339893: lock_release: 0000000084e3738a &mm->mmap_lock
> >             bash-1040    [004] .....    49.339893: sys_exit: NR 109 = 0
> >             bash-1040    [004] .....    49.339893: lock_acquire: 0000000084e3738a read &mm->mmap_lock
> >             bash-1040    [004] .....    49.339894: lock_release: 0000000084e3738a &mm->mmap_lock
> >             bash-1040    [004] .....    49.339894: sys_setpgid -> 0x0
> >             bash-1040    [004] .....    49.339895: lock_release: 00000000f5b22878 rcu_read_lock_trace
> >             bash-1040    [004] d....    49.339895: irq_disable: caller=do_syscall_64+0x37a/0x9a0 parent=0x0
> >             bash-1040    [004] d....    49.339895: irq_enable: caller=do_syscall_64+0x167/0x9a0 parent=0x0
> >             bash-1040    [004] d....    49.339897: irq_disable: caller=irqentry_enter+0x57/0x60 parent=0x0
> > 
> > I did some minor testing of this patch both with and without PREEMPT_RT
> > enabled. This replaces this current patch. Feel free to use it.  
> 
> OK, I will add it with your SoB and give it a spin.  Thank you!

Signed-off-by: Steve Rostedt (Google) <rostedt@goodmis.org>

Cheers,

-- Steve