On Thu, Aug 6, 2026 at 5:22 PM Song Liu <[email protected]> wrote: > > On Thu, Aug 6, 2026 at 8:30 AM Andrey Grodzovsky > <[email protected]> wrote: > > > > Writing 0 to kernel.ftrace_enabled has not reliably disabled ftrace > > for years (FTRACE_OPS_FL_PERMANENT users already block it, and more > > callers rely on ftrace always being on). Refuse the write instead of > > leaving it in an inconsistent "disables some, not all" state: return > > -EOPNOTSUPP and log a message. Reads and enabling (writing 1) are > > unaffected. > > > > Update the docs to note the deprecation up front. > > > > Suggested-by: Steven Rostedt <[email protected]> > > Signed-off-by: Andrey Grodzovsky <[email protected]> > > Sashiko's comments make sense. Other than those: >
The bot has 2 comments. In my opinion, the test-breaking comment is wrong as he looked strictly at this patch w/o reviewing the follow-up live patch testing changes which update the tests to avoid breaks. The cleanup comment is valid but since we aren't sure if we'll need to revert this change later if it breaks userspace in some unseen way, I wonder how extensive the cleanup should be? Steven, can you advise please ? Andrey > Acked-by: Song Liu <[email protected]> > > > --- > > Documentation/trace/ftrace.rst | 5 ++++ > > kernel/trace/ftrace.c | 43 +++++----------------------------- > > 2 files changed, 11 insertions(+), 37 deletions(-) > >
