Re: [RFC PATCH bpf-next 0/3] ftrace, kprobes, bpf: mark trampoline/kprobe ftrace_ops permanent

On Wed, 29 Jul 2026 08:47:33 -0700
Linus Torvalds [off-list ref] wrote:

On Wed, 29 Jul 2026 at 08:31, Steven Rostedt [off-list ref] wrote:

quoted

quoted

quoted

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 -  

It's actually if Linus is OK with this approach.  

The rule is always the same, and I don't understand why there's any
discussion about it because it's been stated a million times: we can
try to make any ABI changes at all, and what matters is whether it
breaks somebodys setup.

If people rely on old behavior, it can't change. And if people don't,
nobody cares. It really is that simple. That is literally the
DEFINITION of "don't break user space".

That's basically what I said. I was just restating it and not asking if I
was correct. I added you more for the below information you added.

Whether something is user-*VISIBLE* in theory is entirely immaterial
except in the sense of "be careful, this needs testing and may have to
be reverted". So user-visibility isn't a "don't do it", it's a "do it
carefully, and knowing that you may have to revert immediately if
somebody complains".

Totally agree.

So changing user-visible things is potentially a lot of wasted effort,
and needs loving care and follow-up.

So everybody should typically avoid changing user-visible things
because it's potentially painful and developer-intensive, but not
because it can't be done.

All that matters is whether real user workloads regress.

And please make sure that any changed behaviour is really obvious, so
that people don't spend lots of time chasing down *why* something
broke. A kernel printk is generally way too subtle - and no, the
tracing "make the printk extra ugly with crazy ASCII barfics" model is
not an improvement.

It might be better to actually return an error to user space so that
users can see that setting ftrace_enabled to zero failed and it would
show up in user logs. kernel developers may think that kernel logs are
important, but users seldom even think about them. Of course, that can
then cause even worse regressions, so there's a balance here.

End result: don't do user visible changes unless you really really
care. And then you spend the extra effort.

Honestly, I don't know of any tooling that would use this kill-switch or
any reason to do so. For live kernel patching and for BPF, it doesn't even
work. Hasn't for some time. It's now a "kill some ftrace but not all".

Hence, again, the switch itself is rather useless.

It now is starting to cause a burden, as there's internal code depending on
ftrace functionality to always be working and can cause some nasty
undefined behavior if someone were to set that kill switch to zero. The
solution is to either play whack-a-mole and make sure all those use cases
have the PERMANENT flag set so the kill-switch does not affect them. Or we
simply disable the kill-switch.

But I like your idea about it returning -ENOSUP if someone tries to set it
to zero. Doing that and the printk should let people know why it didn't
work if they do care.

And yes, we need to be ready to revert it if someone does come back and say
their tooling broke because of it.

Andrey, care to make a patch to do that?

Have setting it to zero return -ENOSUP and print a message saying:

 "The ftrace_enabled file is deprecated and no longer disables ftrace"

-- Steve