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 [off-list ref] wrote:

quoted

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(&current->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;