Messages in this thread Patch in this message | | | Date | Fri, 20 Jan 2023 10:51:18 +0100 | From | Peter Zijlstra <> | 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@infradead.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;
| |