Hi, On Wed, 29 Jul 2026, Andrey Grodzovsky wrote:
> , > > 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. It would be nice to drop ftrace_enabled altogether because your patch set just proves that it is completely uses nowadays. Ack to it. At the same time I have doubts based on the experience with our SLES and how difficult it is to drop a single feature because there is always someone somewhere using even the obscure ones (and sometimes in a very weird way). Fingers crossed. Miroslav
