On Wed, Feb 28, 2024 at 01:16:04PM -0800, Paul E. McKenney wrote:

On Wed, Feb 28, 2024 at 03:22:36PM -0500, Steven Rostedt wrote:

quoted

On Wed, 28 Feb 2024 11:38:29 -0800
"Paul E. McKenney" [off-list ref] wrote:

quoted

The advent of CONFIG_PREEMPT_AUTO, AKA lazy preemption, will mean that
even kernels built with CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY
might see the occasional preemption, and that this preemption just might
happen within a trampoline.

Therefore, update ftrace_shutdown() to invoke synchronize_rcu_tasks()
based on CONFIG_TASKS_RCU instead of CONFIG_PREEMPTION.

Only build tested.

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Ankur Arora <redacted>
Cc: Thomas Gleixner <redacted>
Cc: <redacted>

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 2da4eaa2777d6..c9e6c69cf3446 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c

@@ -3156,7 +3156,7 @@ int ftrace_shutdown(struct ftrace_ops *ops, int command)
 		 * synchronize_rcu_tasks() will wait for those tasks to
 		 * execute and either schedule voluntarily or enter user space.
 		 */
-		if (IS_ENABLED(CONFIG_PREEMPTION))
+		if (IS_ENABLED(CONFIG_TASKS_RCU))
 			synchronize_rcu_tasks();

What happens if CONFIG_TASKS_RCU is not enabled? Does
synchronize_rcu_tasks() do anything? Or is it just a synchronize_rcu()?

It is just a synchronize_rcu().

quoted

If that's the case, perhaps just remove the if statement and make it:

	synchronize_rcu_tasks();

Not sure an extra synchronize_rcu() will hurt (especially after doing a
synchronize_rcu_tasks_rude() just before hand!

That would work for me.  If there are no objections, I will make this
change.

But I did check the latency of synchronize_rcu_tasks_rude() (about 100ms)
and synchronize_rcu() (about 20ms).  This is on a 80-hardware-thread
x86 system that is being flooded with calls to one or the other of
these two functions, but is otherwise idle.  So adding that unnecessary
synchronize_rcu() adds about 20% to that synchronization delay.

Which might still be OK, but...  In the immortal words of MS-DOS,
"Are you sure?".  ;-)

							Thanx, Paul