On Wed, Jul 29, 2026 at 1:32 PM Steven Rostedt <[email protected]> wrote: > > 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
Gladly! As BPF users we can attest that this switch causes pain and handling complications. Should I also clean up the entire PERMANENT flag logic we now have and drop the flag itself? Thanks, Andrey
