On Wed, 21 Oct 2026 16:38:03 -0700 Song Liu <[email protected]> wrote: > On Wed, Oct 21, 2026 at 4:09 PM <[email protected]> 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 <[email protected]> > > > > 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
