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

On Thu, Aug 20, 2026 at 6:20 PM Steven Rostedt <[email protected]> wrote:
>
> On Thu, 20 Aug 2026 17:30:40 -0400
> Andrey Grodzovsky <[email protected]> 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 https://urldefense.com/v3/__http://test-ftrace.sh__;!!BmdzS3_lV9HdKG8!1ja9D51Ex2VTTMdOEl4Eb-3ORL8CXBX1biYMPMLmT1iP3r8I8tfDE41DOth6sc54E3ODLfRqYSaIdTR60lcLWOzKIOK6Jg$  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://urldefense.com/v3/__https://lore.kernel.org/bpf/[email protected]/__;!!BmdzS3_lV9HdKG8!1ja9D51Ex2VTTMdOEl4Eb-3ORL8CXBX1biYMPMLmT1iP3r8I8tfDE41DOth6sc54E3ODLfRqYSaIdTR60lcLWOzV4jPY7w$
> >   - RFC v3 (final):
> > https://urldefense.com/v3/__https://lore.kernel.org/bpf/[email protected]/__;!!BmdzS3_lV9HdKG8!1ja9D51Ex2VTTMdOEl4Eb-3ORL8CXBX1biYMPMLmT1iP3r8I8tfDE41DOth6sc54E3ODLfRqYSaIdTR60lcLWOxUSL-qOg$
> >
> > 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://urldefense.com/v3/__https://lore.kernel.org/all/[email protected]/__;!!BmdzS3_lV9HdKG8!1ja9D51Ex2VTTMdOEl4Eb-3ORL8CXBX1biYMPMLmT1iP3r8I8tfDE41DOth6sc54E3ODLfRqYSaIdTR60lcLWOyr231hEA$
>
> 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

I see, ok, I will add this to my TODO list.

Thanks,
Andrey