FAILED: patch "[PATCH] ftrace: Setup correct FTRACE_FL_REGS flags for module" failed to apply to 4.4-stable tree
Subsystems (3)
[email protected]
maintainerThe patch below does not apply to the 4.4-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 8a224ffb3f52b0027f6b7279854c71a31c48fc97 Mon Sep 17 00:00:00 2001
From: Chengming Zhou <[email protected]>
Date: Wed, 29 Jul 2020 02:05:53 +0800
Subject: [PATCH] ftrace: Setup correct FTRACE_FL_REGS flags for module
When module loaded and enabled, we will use __ftrace_replace_code for module if any ftrace_ops referenced it found. But we will get wrong ftrace_addr for module rec in ftrace_get_addr_new, because rec->flags has not been setup correctly. It can cause the callback function of a ftrace_ops has FTRACE_OPS_FL_SAVE_REGS to be called with pt_regs set to NULL.
So setup correct FTRACE_FL_REGS flags for rec when we call referenced_filters to find ftrace_ops references it.
kernel/trace/ftrace.c +7 -4
@@ -6198,8 +6198,11 @@ static int referenced_filters(struct dyn_ftrace *rec)int cnt =0 ;for (ops = ftrace_ops_list; ops != &ftrace_list_end; ops = ops->next) { -if (ops_references_rec (ops, rec)) - cnt++; +if (ops_references_rec (ops, rec)) { + cnt++; +if (ops->flags &FTRACE_OPS_FL_SAVE_REGS ) + rec->flags |=FTRACE_FL_REGS ; + } }return cnt;
@@ -6378,8 +6381,8 @@ void ftrace_module_enable(struct module *mod)if (ftrace_start_up) cnt +=referenced_filters (rec); -/* This clears FTRACE_FL_DISABLED */ - rec->flags = cnt; + rec->flags &= ~FTRACE_FL_DISABLED ; + rec->flags += cnt;if (ftrace_start_up && cnt) {int failed =__ftrace_replace_code (rec,1 );
Steven Rostedt
maintainerQuoted 4 lines · On Wed, 19 Aug 2020 14:29:11 +0200 <[email protected]> wrote:
The patch below does not apply to the 4.4-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]>.
This should be the fix for 4.4.
-- Steve
From 8a224ffb3f52b0027f6b7279854c71a31c48fc97 Mon Sep 17 00:00:00 2001
From: Chengming Zhou <[email protected]>
Date: Wed, 29 Jul 2020 02:05:53 +0800
Subject: [PATCH] ftrace: Setup correct FTRACE_FL_REGS flags for module
When module loaded and enabled, we will use __ftrace_replace_code for module if any ftrace_ops referenced it found. But we will get wrong ftrace_addr for module rec in ftrace_get_addr_new, because rec->flags has not been setup correctly. It can cause the callback function of a ftrace_ops has FTRACE_OPS_FL_SAVE_REGS to be called with pt_regs set to NULL.
So setup correct FTRACE_FL_REGS flags for rec when we call referenced_filters to find ftrace_ops references it.
kernel/trace/ftrace.c +6 -3
@@ -2823,8 +2823,11 @@ static int referenced_filters(struct dynint cnt =0 ;for (ops = ftrace_ops_list; ops != &ftrace_list_end; ops = ops->next) { -if (ops_references_rec (ops, rec)) - cnt++; +if (ops_references_rec (ops, rec)) { + cnt++; +if (ops->flags &FTRACE_OPS_FL_SAVE_REGS ) + rec->flags |=FTRACE_FL_REGS ; + } }return cnt;
@@ -2874,7 +2877,7 @@ static int ftrace_update_code(struct mod p = &pg->records[i];if (test) cnt +=referenced_filters (p); - p->flags = cnt; + p->flags += cnt;/* * Do the initial record conversion from mcount jump
Quoted 10 lines · Steven Rostedt
Quoted 4 lines · On Wed, 19 Aug 2020 14:29:11 +0200 <[email protected]> wrote:
The patch below does not apply to the 4.4-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]>.This should be the fix for 4.4.
Queued up, thanks!
Signature · 2 lines
Thanks, Sasha