Re: [STABLE REQUEST] ftrace: deprecate the ftrace_enabled disable switch

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 20 Aug 2026 17:30:40 -0400
Andrey Grodzovsky <andrey.grodzovsky@crowdstrike.com> wrote:

> Hello stable team,
> 
> Please consider backporting the following two commits to the stable trees:
> 
>   - b0c857049153680e1b6ccb59abf359a4ca523561 ("ftrace: deprecate
> disabling via ftrace_enabled sysctl")
>   - 88b3e7fedc07d940c32eb5c0733a780e944b6b47 ("selftests/livepatch:
> update test-ftrace.sh for deprecated ftrace_enabled")
> 
> Both commits were merged into mainline in v7.3 via the 'ftrace-v7.3' tag.
> 
> This change addresses a long-standing issue: setting
> kernel.ftrace_enabled=0 silently disables BPF trampolines
> (fentry/fexit) and ftrace-based kprobes/kretprobes. The write succeeds
> and the hooks stop firing without error, while re-enabling silently
> restores them. Livepatch resolved this via FTRACE_OPS_FL_PERMANENT,
> which blocks disabling ftrace while a permanent ops is registered and
> blocks registration while ftrace is disabled. Trampolines had this
> same protection from 2019 to 2022 while sharing a global direct_ops
> marked permanent, but lost it during the 2022 per-trampoline-ops
> split. ftrace based Kprobes never had this protection.
> 
> The breakage was introduced in commit 00963a2e75a8 ("bpf: Support
> bpf_trampoline on functions with IPMODIFY (e.g. livepatch)").
> 
> With these commits, writing 0 is refused with -EOPNOTSUPP and a
> one-time warning is logged; reads and writing 1 are unaffected. Steven
> Rostedt requested and reviewed this change on the mailing list,
> including the follow-up selftest update.
> 
> We would like to backport this to LTS branches starting with 6.1.y,
> where the breaking commit already exists.
> 
> Mailing list threads for reference:
> 
>   - RFC v1: https://lore.kernel.org/bpf/20260730163544.2042327-1-andrey.grodzovsky@crowdstrike.com/
>   - RFC v3 (final):
> https://lore.kernel.org/bpf/20260806153000.4184871-1-andrey.grodzovsky@crowdstrike.com/
> 
> I can provide rebased backports for any trees where these commits do
> not apply cleanly.

I'm really nervous about backporting patches that may be reverted
upstream. These change user space API and if anything depends on the
old behavior, it will be reverted. That would also mean stable would
need to revert it too.

Instead, please post the first two patches of your original series:

  https://lore.kernel.org/all/20260729005959.3853865-1-andrey.grodzovsky@crowdstrike.com/

I rather push these upstream even if they are not really needed. But
those are much safer to backport because it "fixes" the problem even if
the main fix gets reverted.

-- Steve