From: Frederic Weisbecker <fweisbec@gmail.com>
To: Matt Fleming <matt@console-pimps.org>,
Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH] tracing: Fix infinite loop in ftrace_update_pid_func()
Date: Tue, 29 Sep 2009 11:22:47 +0200 [thread overview]
Message-ID: <20090929092245.GA5057@nowhere> (raw)
In-Reply-To: <1254152581-18347-1-git-send-email-matt@console-pimps.org>
On Mon, Sep 28, 2009 at 04:43:01PM +0100, Matt Fleming wrote:
> From: Matt Fleming <matthew.fleming@imgtec.com>
>
> When CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST is enabled
> __ftrace_trace_function contains the current trace function, not
> ftrace_trace_function. In ftrace_update_pid_func() we currently
> incorrectly assign the value of ftrace_trace_function to
> __ftrace_trace_funcion before returning.
>
> Without this patch it is possible to execute an infinite loop whereby
> ftrace_test_stop_func() calls __ftrace_trace_function, which was
> assigned ftrace_test_stop_func() in ftrace_update_pid_func().
>
> Signed-off-by: Matt Fleming <matthew.fleming@imgtec.com>
> ---
> kernel/trace/ftrace.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 25edd5c..d9ba6d9 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -225,7 +225,11 @@ static void ftrace_update_pid_func(void)
> if (ftrace_trace_function == ftrace_stub)
> return;
>
> +#ifdef CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST
> func = ftrace_trace_function;
> +#else
> + func = __ftrace_trace_function;
> +#endif
I don't understand how it can do that infinite loop.
It doesn't seem the following can happen:
func = ftrace_trace_function //which is ftrace_test_stop_func
_ftrace_trace_function = func
Because we can sum up the path like that:
func = ftrace_trace_function;
...
#ifdef CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST
ftrace_trace_function = func;
#else
__ftrace_trace_function = func;
#endif
So if we are in CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST,
that doesn't seem to harm, although it seems that what we want is
func = __ftrace_trace_function
...
__ftrace_trace_function = func
Because we want to always keep ftrace_test_stop_func as the top level
wrapper. Which would be what does the above, plus the fact we avoid any
recursivity.
But it's possible I'm missing the point...
Also, Steve, is this an option that is still useful? It's even not
in Kconfig.
next prev parent reply other threads:[~2009-09-29 9:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-28 15:43 [PATCH] tracing: Fix infinite loop in ftrace_update_pid_func() Matt Fleming
2009-09-29 9:22 ` Frederic Weisbecker [this message]
2009-09-29 9:44 ` Matt Fleming
2009-09-30 8:41 ` Steven Rostedt
2009-09-30 8:51 ` Matt Fleming
2009-09-29 9:51 ` Matt Fleming
2009-10-01 6:48 ` [tip:tracing/urgent] tracing: Fix infinite recursion " tip-bot for Matt Fleming
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=20090929092245.GA5057@nowhere \
--to=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@console-pimps.org \
--cc=mingo@redhat.com \
--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