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. > -- > > 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. Thanks, Song > > Because __always_inline only inherits notrace through inline, removing > notrace here strips notrace from both inline and __always_inline functions > whenever their address is taken and the compiler emits an out-of-line copy. > [...]
