This addresses 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.
The solution chosen is to deny setting this knob to 0 from userspace,
thus preventing this case in the first place. Steven mentioned that the
switch became effectively useless and doesn't serve any meaningful
purpose anymore, and only creates problems for systems that rely on
ftrace, such as Livepatching and eBPF. Any attempt to set it to 0 will
fail with -EOPNOTSUPP. Reading and writing 1 remain unchanged.
Patch 1: the sysctl change plus a doc note.
Patch 2: updates the one selftest that relied on the old disable
behavior.
The original patch-set was a fix to commit 00963a2e75a8 ("bpf: Support
bpf_trampoline on functions with IPMODIFY (e.g. livepatch)"), and so we
would want to see this backported at least to LTS branches starting
with 6.1. But since this is effectively a new behavior and not a bug
fix, I am not sure what the policy is in this case.
Changes since v2:
- Remove unused ftrace_shutdown_sysctl() and
is_permanent_ops_registered() functions entirely instead of keeping
them with __maybe_unused. (Steven)
- Fix ftrace_disable_supported() to save and restore the original
kernel.ftrace_enabled value instead of unconditionally forcing it to
1. (Joe)
[1]
https://lore.kernel.org/bpf/[email protected]/
Andrey Grodzovsky (2):
ftrace: deprecate disabling via ftrace_enabled sysctl
selftests/livepatch: update test-ftrace.sh for deprecated
ftrace_enabled
Documentation/trace/ftrace.rst | 5 +++
kernel/trace/ftrace.c | 43 +++---------------
.../testing/selftests/livepatch/functions.sh | 14 ++++++
.../selftests/livepatch/test-ftrace.sh | 45 ++++++++++++-------
4 files changed, 53 insertions(+), 54 deletions(-)
--
2.34.1
