All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	stable@kernel.org,
	"Luis Claudio R. Goncalves" <lclaudio@uudg.org>,
	Oleg Nesterov <oleg@tv-sign.ru>
Subject: Re: [PATCH 2/3] function-graph: enable the stack after initialization of other variables
Date: Tue, 2 Jun 2009 21:02:29 +0200	[thread overview]
Message-ID: <20090602190227.GB6041@nowhere> (raw)
In-Reply-To: <20090602184601.206454309@goodmis.org>

On Tue, Jun 02, 2009 at 02:30:38PM -0400, Steven Rostedt wrote:
> From: Steven Rostedt <srostedt@redhat.com>
> 
> The function graph tracer checks if the task_struct has ret_stack defined
> to know if it is OK or not to use it. The initialization is done for
> all tasks by one process, but the idle tasks use the same initialization
> used by new tasks.
> 
> If an interrupt happens on an idle task that just had the ret_stack
> created, but before the rest of the initialization took place, then
> we can corrupt the return address of the functions.
> 
> This patch moves the setting of the task_struct's ret_stack to after
> the other variables have been initialized.
> 
> [ Impact: prevent kernel panic on idle task when starting function graph ]
> 
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> ---
>  kernel/trace/ftrace.c                |    9 +++++++--
>  kernel/trace/trace_functions_graph.c |    6 ++++++
>  2 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index ebff62e..20e0660 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -2739,15 +2739,20 @@ void unregister_ftrace_graph(void)
>  void ftrace_graph_init_task(struct task_struct *t)
>  {
>  	if (atomic_read(&ftrace_graph_active)) {
> -		t->ret_stack = kmalloc(FTRACE_RETFUNC_DEPTH
> +		struct ftrace_ret_stack *ret_stack;
> +
> +		ret_stack = kmalloc(FTRACE_RETFUNC_DEPTH
>  				* sizeof(struct ftrace_ret_stack),
>  				GFP_KERNEL);
> -		if (!t->ret_stack)
> +		if (!ret_stack)
>  			return;
>  		t->curr_ret_stack = -1;
>  		atomic_set(&t->tracing_graph_pause, 0);
>  		atomic_set(&t->trace_overrun, 0);
>  		t->ftrace_timestamp = 0;
> +		/* make curr_ret_stack visable before we add the ret_stack */
> +		smp_wmb();
> +		t->ret_stack = ret_stack;
>  	} else
>  		t->ret_stack = NULL;
>  }


Thanks for fixing this.


> diff --git a/kernel/trace/trace_functions_graph.c b/kernel/trace/trace_functions_graph.c
> index d28687e..baeb5fe 100644
> --- a/kernel/trace/trace_functions_graph.c
> +++ b/kernel/trace/trace_functions_graph.c
> @@ -65,6 +65,12 @@ ftrace_push_return_trace(unsigned long ret, unsigned long func, int *depth)
>  	if (!current->ret_stack)
>  		return -EBUSY;
>  
> +	/*
> +	 * We must make sure the ret_stack is tested before we read
> +	 * anything else.
> +	 */
> +	smp_rmb();


Isn't this part a too much costly for very traced function?


> +
>  	/* The return trace stack is full */
>  	if (current->curr_ret_stack == FTRACE_RETFUNC_DEPTH - 1) {
>  		atomic_inc(&current->trace_overrun);
> -- 
> 1.6.3.1
> 
> -- 


  reply	other threads:[~2009-06-02 19:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-02 18:30 [PATCH 0/3] [GIT PULL][urgent] function-graph: memory leak and race fixes Steven Rostedt
2009-06-02 18:30 ` [PATCH 1/3] function-graph: only allocate init tasks if it was not already done Steven Rostedt
2009-06-02 18:30 ` [PATCH 2/3] function-graph: enable the stack after initialization of other variables Steven Rostedt
2009-06-02 19:02   ` Frederic Weisbecker [this message]
2009-06-02 19:30     ` Steven Rostedt
2009-06-03 15:35       ` Paul E. McKenney
2009-06-02 18:30 ` [PATCH 3/3] function-graph: add memory barriers for accessing tasks ret_stack 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=20090602190227.GB6041@nowhere \
    --to=fweisbec@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=lclaudio@uudg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@tv-sign.ru \
    --cc=rostedt@goodmis.org \
    --cc=stable@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.