[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y8pkFhi32XhvCVOo@hirez.programming.kicks-ass.net>
Date: Fri, 20 Jan 2023 10:51:18 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: kernel test robot <oliver.sang@...el.com>, oe-lkp@...ts.linux.dev,
lkp@...el.com, linux-kernel@...r.kernel.org, x86@...nel.org,
Ingo Molnar <mingo@...nel.org>,
linux-trace-kernel@...r.kernel.org
Subject: Re: [tip:sched/core] [tracing, hardirq] 9aedeaed6f:
WARNING:suspicious_RCU_usage
On Thu, Jan 19, 2023 at 11:24:33AM -0500, Steven Rostedt wrote:
> On Thu, 19 Jan 2023 16:45:49 +0100
> Peter Zijlstra <peterz@...radead.org> wrote:
>
> > Steve, what's the easiest way to figure out what triggers this? Put a
> > printk() in prepare_ftrace_return() or so?
>
> Does it only trigger if all functions are enabled when running function
> graph tracer?
>
> That is, if you just trace one function, say "schedule" does it
> have an issue?
>
> trace-cmd start -p function_graph -l schedule
>
> And then run your code, and it doesn't trigger, but:
>
>
> trace-cmd reset # make sure schedule is no longer filtered
> trace-cmd start -p function_graph
>
> does trigger the issue, you can then bisect the functions with the script:
>
> scripts/tracing/ftrace-bisect.sh
Pff, that all sounds like actual work :-)
Instead I did me the below hack and added my early_printk() hacks and
that got me a usable backtrace.
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index 5e7ead52cfdb..7defc6e24f8f 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -646,6 +646,9 @@ void prepare_ftrace_return(unsigned long ip, unsigned long *parent,
if (unlikely(atomic_read(¤t->tracing_graph_pause)))
return;
+ if (WARN_ONCE(!rcu_is_watching(), "RCU not on for: %pS\n", (void *)ip))
+ return;
+
bit = ftrace_test_recursion_trylock(ip, *parent);
if (bit < 0)
return;
Powered by blists - more mailing lists