On Wed, 29 Jul 2026 08:47:33 -0700 Linus Torvalds <[email protected]> wrote:
> On Wed, 29 Jul 2026 at 08:31, Steven Rostedt <[email protected]> wrote: > > > > > > 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
