FAILED: patch "[PATCH] ftrace: Handle commands when closing set_ftrace_filter file" failed to apply to 4.14-stable tree
Subsystems (3)
[email protected]
maintainerThe patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 8c9af478c06bb1ab1422f90d8ecbc53defd44bc3 Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (VMware)" <[email protected]>
Date: Wed, 5 May 2021 10:38:24 -0400
Subject: [PATCH] ftrace: Handle commands when closing set_ftrace_filter file
# echo switch_mm:traceoff > /sys/kernel/tracing/set_ftrace_filter
will cause switch_mm to stop tracing by the traceoff command.
# echo -n switch_mm:traceoff > /sys/kernel/tracing/set_ftrace_filter
does nothing.
The reason is that the parsing in the write function only processes commands if it finished parsing (there is white space written after the command). That's to handle:
write(fd, "switch_mm:", 10);
write(fd, "traceoff", 8);
cases, where the command is broken over multiple writes.
The problem is if the file descriptor is closed, then the write call is not processed, and the command needs to be processed in the release code. The release code can handle matching of functions, but does not handle commands.
kernel/trace/ftrace.c +4 -1
@@ -5591,7 +5591,10 @@ int ftrace_regex_release(struct inode *inode, struct file *file) parser = &iter->parser;if (trace_parser_loaded (parser)) { -ftrace_match_records (iter->hash, parser->buffer, parser->idx); +int enable = !(iter->flags &FTRACE_ITER_NOTRACE ); + +ftrace_process_regex (iter, parser->buffer, + parser->idx, enable); }trace_parser_put (parser);
Steven Rostedt
maintainerQuoted 9 lines · On Fri, 07 May 2021 15:51:13 +0200 <[email protected]> wrote:
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.thanks,
greg k-h
Below is the patch that works for 4.14. I'm currently working on a fix for 4.9 and 4.4 as this does not apply to them.
-- Steve
Quoted 1 line
From
8c9af478c06bb1ab1422f90d8ecbc53defd44bc3Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (VMware)" <[email protected]>
Date: Wed, 5 May 2021 10:38:24 -0400
Subject: [PATCH] ftrace: Handle commands when closing set_ftrace_filter file
# echo switch_mm:traceoff > /sys/kernel/tracing/set_ftrace_filter
will cause switch_mm to stop tracing by the traceoff command.
# echo -n switch_mm:traceoff > /sys/kernel/tracing/set_ftrace_filter
does nothing.
The reason is that the parsing in the write function only processes commands if it finished parsing (there is white space written after the command). That's to handle:
write(fd, "switch_mm:", 10);
write(fd, "traceoff", 8);
cases, where the command is broken over multiple writes.
The problem is if the file descriptor is closed, then the write call is not processed, and the command needs to be processed in the release code. The release code can handle matching of functions, but does not handle commands.
kernel/trace/ftrace.c +4 -1
@@ -5096,8 +5096,11 @@ int ftrace_regex_release(struct inode *i parser = &iter->parser;if (trace_parser_loaded (parser)) { +int enable = !(iter->flags &FTRACE_ITER_NOTRACE ); + parser->buffer[parser->idx] =0 ; -ftrace_match_records (iter->hash, parser->buffer, parser->idx); +ftrace_process_regex (iter, parser->buffer, + parser->idx, enable); }trace_parser_put (parser);
Greg KH
maintainerQuoted 8 lines · Steven Rostedt
Quoted 5 lines · On Fri, 07 May 2021 15:51:13 +0200 <[email protected]> wrote:
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
Quoted 7 lines
Quoted 4 lines
thanks,
greg k-h
Below is the patch that works for 4.14. I'm currently working on a fix for 4.9 and 4.4 as this does not apply to them.
All backports now queued up, thanks!
greg k-h