FAILED: patch "[PATCH] tracing: Dump stacktrace trigger to the corresponding" failed to apply to 4.14-stable tree
Subsystems (2)
[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 ce33c845b030c9cf768370c951bc699470b09fa7 Mon Sep 17 00:00:00 2001
From: Daniel Bristot de Oliveira <[email protected]>
Date: Sun, 20 Feb 2022 23:49:57 +0100
Subject: [PATCH] tracing: Dump stacktrace trigger to the corresponding
instance
The stacktrace event trigger is not dumping the stacktrace to the instance where it was enabled, but to the global "instance."
Use the private_data, pointing to the trigger file, to figure out the corresponding trace instance, and use it in the trigger action, like snapshot_trigger does.
kernel/trace/trace_events_trigger.c +6 -1
@@ -1540,7 +1540,12 @@ stacktrace_trigger(struct event_trigger_data *data, struct trace_buffer *buffer, void *rec, struct ring_buffer_event *event) { -trace_dump_stack (STACK_SKIP ); + struct trace_event_file *file = data->private_data; + +if (file) +__trace_stack (file->tr,tracing_gen_ctx (),STACK_SKIP ); +else +trace_dump_stack (STACK_SKIP ); } static void
Quoted 5 lines · On Mon, 28 Feb 2022 08:30:29 +0100 <[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]>.
The following should work for 4.14. Again, 4.9 and earlier requires a lot more work than I have time for.
-- Steve
Quoted 1 line
From
ce33c845b030c9cf768370c951bc699470b09fa7Mon Sep 17 00:00:00 2001
From: Daniel Bristot de Oliveira <[email protected]>
Date: Sun, 20 Feb 2022 23:49:57 +0100
Subject: [PATCH] tracing: Dump stacktrace trigger to the corresponding
instance
The stacktrace event trigger is not dumping the stacktrace to the instance where it was enabled, but to the global "instance."
Use the private_data, pointing to the trigger file, to figure out the corresponding trace instance, and use it in the trigger action, like snapshot_trigger does.
--- kernel/trace/trace_events_trigger.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
kernel/trace/trace_events_trigger.c +8 -1
@@ -1156,7 +1156,14 @@ static __init int register_trigger_snapsstatic void stacktrace_trigger (struct event_trigger_data *data,void *rec) { -trace_dump_stack (STACK_SKIP ); +struct trace_event_file *file = data->private_data; +unsigned long flags; + +if (file) { +local_save_flags (flags); +__trace_stack (file->tr, flags,STACK_SKIP ,preempt_count ()); + }else +trace_dump_stack (STACK_SKIP ); } static void
Greg KH
maintainerQuoted 11 lines · Steven Rostedt
Quoted 5 lines · On Mon, 28 Feb 2022 08:30:29 +0100 <[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]>.The following should work for 4.14. Again, 4.9 and earlier requires a lot more work than I have time for.
All now queued up, thanks.
greg k-h