All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "Paul E. McKenney" <paulmck@us.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>, Tejun Heo <tj@kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Jiri Olsa <jolsa@redhat.com>
Subject: Re: [RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavy synchronize_sched()
Date: Wed, 5 Jun 2013 13:51:47 +0200	[thread overview]
Message-ID: <20130605115147.GF8923@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1369785676.15552.55.camel@gandalf.local.home>

On Tue, May 28, 2013 at 08:01:16PM -0400, Steven Rostedt wrote:
> The function tracer uses preempt_disable/enable_notrace() for
> synchronization between reading registered ftrace_ops and unregistering
> them.
> 
> Most of the ftrace_ops are global permanent structures that do not
> require this synchronization. That is, ops may be added and removed from
> the hlist but are never freed, and wont hurt if a synchronization is
> missed.
> 
> But this is not true for dynamically created ftrace_ops or control_ops,
> which are used by the perf function tracing.
> 
> The problem here is that the function tracer can be used to trace
> kernel/user context switches as well as going to and from idle.
> Basically, it can be used to trace blind spots of the RCU subsystem.
> This means that even though preempt_disable() is done, a
> synchronize_sched() will ignore CPUs that haven't made it out of user
> space or idle. These can include functions that are being traced just
> before entering or exiting the kernel sections.
> 
> To implement the RCU synchronization, instead of using
> synchronize_sched() the use of schedule_on_each_cpu() is performed. This
> means that when a dynamically allocated ftrace_ops, or a control ops is
> being unregistered, all CPUs must be touched and execute a ftrace_sync()
> stub function via the work queues. This will rip CPUs out from idle or
> in dynamic tick mode. This only happens when a user disables perf
> function tracing or other dynamically allocated function tracers, but it
> allows us to continue to debug RCU and context tracking with function
> tracing.
> 
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> 
> Index: linux-trace.git/kernel/trace/ftrace.c
> ===================================================================
> --- linux-trace.git.orig/kernel/trace/ftrace.c
> +++ linux-trace.git/kernel/trace/ftrace.c
> @@ -413,6 +413,17 @@ static int __register_ftrace_function(st
>  	return 0;
>  }
>  
> +static void ftrace_sync(struct work_struct *work)
> +{
> +	/*
> +	 * This function is just a stub to implement a hard force
> +	 * of synchronize_sched(). This requires synchronizing
> +	 * tasks even in userspace and idle.
> +	 *
> +	 * Yes, function tracing is rude.
> +	 */
> +}
> +
>  static int __unregister_ftrace_function(struct ftrace_ops *ops)
>  {
>  	int ret;
> @@ -440,8 +451,12 @@ static int __unregister_ftrace_function(
>  			 * so there'll be no new users. We must ensure
>  			 * all current users are done before we free
>  			 * the control data.
> +			 * Note synchronize_sched() is not enough, as we
> +			 * use preempt_disable() to do RCU, but the function
> +			 * tracer can be called where RCU is not active
> +			 * (before user_exit()).
>  			 */
> -			synchronize_sched();
> +			schedule_on_each_cpu(ftrace_sync);
>  			control_ops_free(ops);
>  		}
>  	} else
> @@ -456,9 +471,13 @@ static int __unregister_ftrace_function(
>  	/*
>  	 * Dynamic ops may be freed, we must make sure that all
>  	 * callers are done before leaving this function.
> +	 *
> +	 * Again, normal synchronize_sched() is not good enough.
> +	 * We need to do a hard force of sched synchronization.
>  	 */
>  	if (ops->flags & FTRACE_OPS_FL_DYNAMIC)
> -		synchronize_sched();
> +		schedule_on_each_cpu(ftrace_sync);
> +
>  
>  	return 0;
>  }
> 

So what happens if schedule_on_each_cpu() returns -ENOMEM? :-)

  parent reply	other threads:[~2013-06-05 11:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-29  0:01 [RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavy synchronize_sched() Steven Rostedt
2013-05-29  7:52 ` Peter Zijlstra
2013-05-29 13:33   ` Paul E. McKenney
2013-05-29 13:55     ` Steven Rostedt
2013-05-29 13:41   ` Steven Rostedt
2014-06-19  1:56   ` Steven Rostedt
2014-06-19  2:28     ` Paul E. McKenney
2014-06-19  7:18       ` Masami Hiramatsu
2013-05-29  8:23 ` Paul E. McKenney
2013-06-04 11:03 ` Frederic Weisbecker
2013-06-04 12:11   ` Steven Rostedt
2013-06-04 12:30     ` Frederic Weisbecker
2013-06-05 11:51 ` Peter Zijlstra [this message]
2013-06-05 13:36   ` Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130605115147.GF8923@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=fweisbec@gmail.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=paulmck@us.ibm.com \
    --cc=rostedt@goodmis.org \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.