From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
Li Zefan <lizf@cn.fujitsu.com>,
Lai Jiangshan <laijs@cn.fujitsu.com>,
Masami Hiramatsu <mhiramat@redhat.com>
Subject: Re: [RFC PATCH 03/10] ftrace: Drop the ftrace_profile_enabled checks in tracing hot path
Date: Thu, 21 Jan 2010 21:28:58 -0500 [thread overview]
Message-ID: <20100122022858.GA2604@Krystal> (raw)
In-Reply-To: <1264125917.31321.312.camel@gandalf.stny.rr.com>
* Steven Rostedt (rostedt@goodmis.org) wrote:
> On Fri, 2010-01-22 at 02:16 +0100, Frederic Weisbecker wrote:
> > Every time we enter the function profiler tracing callbacks, we first
> > check if the function profiling is enabled.
> >
> > This check is useless because we register the function graph
> > callbacks only after the hashlist has been initialized.
>
> Unfortunately, since the previous patch is incorrect, it makes this one
> buggy too.
>
> If you remove the check to ftrace_profile_enabled, the call to the
> profiled code could have been preempted and pending to be called.
>
> Stop machine may remove all calls to the tracing, but it only affects
> new hits. Pending hits may still exist.
>
> If you remove this check, and the user re-enables the profiling, then
> all PER_CPU hashs will be reset. If in the process of this happening,
> the task with the pending trace wakes up, it may access the PER_CPU list
> and corrupt it.
>
> Now for the reason I Cc'd Paul and Mathieu...
>
> If we had a synchronize_sched() like function that would wait and return
> when all preempted tasks have been scheduled again and went to either
> userspace or called schedule directly, then we could actually do this.
>
> After unregistering the function graph trace, you call this
> "synchronize_tasks()" and it will guarantee that all currently preempted
> tasks have either went to userspace or have called schedule() directly.
> Then it would be safe to remove this check.
OK, so basically you need to know when you reach a quiescent state, but
preemption is enabled and there is no RCU read lock taken around these
code paths, am I correct ?
With tracepoints, life is easy because I disable preemption around the
calls, so I can use synchronize_sched() to know when quiescent state is
reached.
I recommend looking at kernel/kprobes.c:check_safety(). It uses
thaw_processes() and synchronize_sched() for this purpose. Basically, it
rely on the "refrigeration" points to detect such quiescent state. This
trick should do the job for the function graph tracer too.
I'm adding Masami in CC. He is the one who implemented check_safety(),
and I remember discussing it with him in the past.
Thanks,
Mathieu
>
> -- Steve
>
> >
> > Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> > Cc: Steven Rostedt <rostedt@goodmis.org>
> > Cc: Li Zefan <lizf@cn.fujitsu.com>
> > Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
> > ---
> > kernel/trace/ftrace.c | 7 ++-----
> > 1 files changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> > index 94117ec..f258f67 100644
> > --- a/kernel/trace/ftrace.c
> > +++ b/kernel/trace/ftrace.c
> > @@ -381,13 +381,10 @@ function_profile_call(unsigned long ip, unsigned long parent_ip)
> > struct func_node *rec;
> > unsigned long flags;
> >
> > - if (!ftrace_profile_enabled)
> > - return;
> > -
> > local_irq_save(flags);
> >
> > hlist = &__get_cpu_var(func_hlist_cpu);
> > - if (!hlist->hash || !ftrace_profile_enabled)
> > + if (!hlist->hash)
> > goto out;
> >
> > rec = function_find_hlist_node(hlist, ip);
> > @@ -418,7 +415,7 @@ static void profile_graph_return(struct ftrace_graph_ret *trace)
> >
> > local_irq_save(flags);
> > hlist = &__get_cpu_var(func_hlist_cpu);
> > - if (!hlist->hash || !ftrace_profile_enabled)
> > + if (!hlist->hash)
> > goto out;
> >
> > calltime = trace->rettime - trace->calltime;
>
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2010-01-22 2:29 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-22 1:16 [RFC PATCH 00/10] Ftrace functions hashlist Frederic Weisbecker
2010-01-22 1:16 ` [RFC PATCH 01/10] ftrace: Generalize the function hashlist from function profiler Frederic Weisbecker
2010-01-22 1:16 ` [RFC PATCH 02/10] ftrace: Ensure tracing has really stopped before leaving unregister_ftrace_graph Frederic Weisbecker
2010-01-22 1:51 ` Steven Rostedt
2010-01-22 2:04 ` Frederic Weisbecker
2010-01-22 1:16 ` [RFC PATCH 03/10] ftrace: Drop the ftrace_profile_enabled checks in tracing hot path Frederic Weisbecker
2010-01-22 2:05 ` Steven Rostedt
2010-01-22 2:28 ` Mathieu Desnoyers [this message]
2010-01-22 3:12 ` Steven Rostedt
2010-01-22 4:09 ` Mathieu Desnoyers
2010-01-22 4:52 ` Steven Rostedt
2010-01-22 12:34 ` Mathieu Desnoyers
2010-01-22 14:54 ` Masami Hiramatsu
2010-01-25 20:58 ` Frederic Weisbecker
2010-01-25 22:14 ` Masami Hiramatsu
2010-01-26 0:41 ` Frederic Weisbecker
2010-01-26 1:13 ` Mathieu Desnoyers
2010-01-26 1:37 ` Masami Hiramatsu
2010-01-27 21:55 ` [PATCH tracing/kprobes] kprobes: Disable booster when CONFIG_PREEMPT=y Masami Hiramatsu
2010-01-28 1:08 ` Mathieu Desnoyers
2010-01-28 4:21 ` Ananth N Mavinakayanahalli
2010-01-29 9:21 ` Ingo Molnar
2010-01-29 11:30 ` Peter Zijlstra
2010-01-29 14:52 ` Masami Hiramatsu
2010-01-29 17:08 ` Mathieu Desnoyers
2010-01-29 17:15 ` Peter Zijlstra
2010-01-29 17:27 ` Mathieu Desnoyers
2010-01-29 17:32 ` Masami Hiramatsu
2010-01-22 2:43 ` [RFC PATCH 03/10] ftrace: Drop the ftrace_profile_enabled checks in tracing hot path Frederic Weisbecker
2010-01-22 3:05 ` Steven Rostedt
2010-01-25 20:52 ` Frederic Weisbecker
2010-01-22 1:16 ` [RFC PATCH 04/10] ftrace: Ensure buffers are visibles to tracing callbacks right away Frederic Weisbecker
2010-01-22 1:16 ` [RFC PATCH 05/10] ftrace: Drop buffer check in function profiler callbacks Frederic Weisbecker
2010-01-25 6:17 ` Lai Jiangshan
2010-01-30 20:47 ` Frederic Weisbecker
2010-01-22 1:16 ` [RFC PATCH 06/10] ftrace: Release the function hlist if we don't need it anymore Frederic Weisbecker
2010-01-25 6:41 ` Lai Jiangshan
2010-01-30 21:14 ` Frederic Weisbecker
2010-01-22 1:16 ` [RFC PATCH 07/10] ftrace: Make the function hashlist concurrently usable Frederic Weisbecker
2010-01-22 1:16 ` [PATCH 08/10] tracing: Simplify test for function_graph tracing Frederic Weisbecker
2010-01-22 1:16 ` [RFC PATCH 09/10] tracing: Use the hashlist for graph function Frederic Weisbecker
2010-01-25 8:50 ` Lai Jiangshan
2010-01-30 21:19 ` Frederic Weisbecker
2010-01-22 1:16 ` [RFC PATCH 10/10] ftrace: Factorize search and insertion in the function hashlist Frederic Weisbecker
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=20100122022858.GA2604@Krystal \
--to=compudj@krystal.dyndns.org \
--cc=fweisbec@gmail.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox