This adresses 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.
Changes since v1 :
- test-ftrace.sh: keep the full original disable/reload scenario on
kernels where kernel.ftrace_enabled=0 still works, and only fall
back to the simple "write is refused" check on kernels that
deprecate the knob.(Steven)
[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 | 19 ++++----
.../testing/selftests/livepatch/functions.sh | 13 ++++++
.../selftests/livepatch/test-ftrace.sh | 45 ++++++++++++-------
4 files changed, 54 insertions(+), 28 deletions(-)
--
2.34.1
