Re: [PATCH] compiler_types: Do not mark inline functions notrace

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 21 Oct 2026 16:38:03 -0700
Song Liu <song@kernel.org> wrote:

> On Wed, Oct 21, 2026 at 4:09 PM <sashiko-bot@kernel.org> wrote:
> >
> > Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
> > - [Critical] x86/paravirt: removing notrace from inline instruments pv_ops and resume
> > - [High] tracing: removing notrace from inline breaks ftrace recursion protection
> > - [High] rcu: srcu_read_lock_fast_notrace() and tracepoints lose notrace attribute
> > - [High] bpf: removing notrace from inline exposes trampoline helpers to fentry
> > - [High] entry: removing notrace from inline instruments unvalidated entry helpers  
> 
> Wow. I didn't expect this from Sashiko.

Yeah, I was pretty impressed too.

> 
> > --
> >
> > commit 1eb6626c4a5ab70e5858a8a8f1c9edfca235db57
> > Author: Song Liu <song@kernel.org>
> >
> > compiler_types: Do not mark inline functions notrace
> >
> > This commit removes the notrace attribute from the inline macro definition
> > in include/linux/compiler_types.h so that inline functions emitted
> > out-of-line by the compiler can be traced by ftrace, attached to via BPF
> > fentry/fexit, and livepatched.
> >  
> > > diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
> > > index c5921f1390079..ea7f2a928b4da 100644
> > > --- a/include/linux/compiler_types.h
> > > +++ b/include/linux/compiler_types.h
> > > @@ -230,9 +230,8 @@ struct ftrace_likely_data {
> > >   * externally visible function. This makes extern inline behave as per gnu89
> > >   * semantics rather than c99. This prevents multiple symbol definition errors
> > >   * of extern inline functions at link time.
> > > - * A lot of inline functions can cause havoc with function tracing.
> > >   */
> > > -#define inline inline __gnu_inline __inline_maybe_unused notrace
> > > +#define inline inline __gnu_inline __inline_maybe_unused
> > >
> > >  /*
> > >   * gcc provides both __inline__ and __inline as alternate spellings of  
> >
> > [Severity: Critical]
> > Could removing notrace from inline cause a triple-fault during x86 suspend
> > resume, secondary CPU bringup, or kexec when function tracing or call-depth
> > tracking is active?
> >
> > In include/linux/compiler_attributes.h, __always_inline expands to inline:
> >
> >     #define __always_inline inline __attribute__((__always_inline__))  
> 
> I wonder whether we need __always_inline to be notrace, and whether
> this resolves any of these concerns.

Yes, we should add "notrace" to the __always_inline for the reasons given
by sashiko. I'll look a the other comments to see if there's other issues.

-- Steve