, On Wed, Jul 29, 2026 at 10:40 AM Steven Rostedt <[email protected]> wrote: > > On Tue, 28 Jul 2026 20:59:56 -0400 > Andrey Grodzovsky <[email protected]> wrote: > > > This fixes a long-standing issue: kernel.ftrace_enabled=0 silently > > disables BPF trampolines (fentry/fexit) and ftrace-based > > kprobes/kretprobes. The write succeeds, the hook stops firing with no > > error, and re-enabling silently restores it. Livepatch already solved > > this for itself via FTRACE_OPS_FL_PERMANENT, which refuses to disable > > ftrace while a permanent ops is registered and refuses to register > > one while ftrace is disabled[1]. > > The /proc/sys/kernel/ftrace_enabled was added as a "safety kill switch" > back when ftrace was first added to the kernel. It's addition was namely > there because live runtime modification of kernel code was new and we were > worried about how stable it could be. > > Honestly, I would love to get rid of it as today ftrace has proven to be > rather stable. But as it is a user space ABI, I'm not sure what will break > if we do. I wonder if we just make it a nop, and print a message to dmesg > saying: > > "ftrace_enabled no longer does anything. Please report if you need it to." > > ?
Thanks Steven, if you and/or other community members would approve such approach I would happily do this instead for a few reasons - 1) Seems like the more correct course of action if idneed this switch effectively became obsolete in usage instead of piling extra logic to work around it. 2) As I mentioned in the end of the cover letter, I believe for some cases such as fsessions/ksessions and multi opts retprobes, this patchset is not effective and the issue will persist, requiring a more complicated solution for them anyway if we want watertight resilience. If you approve this - I can try what you suggested, this would include making the knob a NOP with a message, dropping the FTRACE_OPS_FL_PERMANENT flag and reverting/cleaning what's possible from the original livepatch patchset that dealt with this issue [1] One question is what the correct set of tests to run in such a case would be to verify we didn't break anything. For this patchset I ran BPF and livepatch selftest suites, but I wonder what else would need to be run. CC Miroslav for Livepatch. Thanks, Andrey [1] - https://lore.kernel.org/all/[email protected]/T/#u > > > > > For trampolines this restores a historical property: from 2019-2022 > > they shared one global direct_ops, marked permanent the same > > way[2].It was later lost as a side effect of the 2022 > > per-trampoline-ops split (patch 1's Fixes tag) and never > > restored.[3][4] Kprobes never carried this protection at all, so > > for them that is long-standing issue rather than a regression. > > > > Patch 1: trampolines. Patch 2: classic kprobes/kretprobes. Patch 3: > > a selftest covering both directions for all four hook types. > > > > P.S > > I initially implemented a per-record opt-in flag[5], but dropped it > > as over-engineering once I saw the original blanket restriction. > > > > P.P.S > > Open question: kprobe.multi/kretprobe.multi/kprobe.session > > (fprobe-backed) aren't covered -- return-capturing fprobes share the > > function-graph tracer's subops manager with unrelated tracers, so > > marking it permanent needs a different, per-record approach. Perhaps > > something along the lines of [5]. > > Honestly, I would like to start deprecating that kill switch. > > For the series: > > Acked-by: Steven Rostedt <[email protected]> > > -- Steve
