All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Li Huafei <lihuafei1@huawei.com>
Cc: <mhiramat@kernel.org>, <mark.rutland@arm.com>,
	<linux-kernel@vger.kernel.org>,
	<linux-trace-kernel@vger.kernel.org>
Subject: Re: [PATCH] ftrace: Fix use-after-free for dynamic ftrace_ops
Date: Wed, 2 Nov 2022 18:53:48 -0400	[thread overview]
Message-ID: <20221102185348.40f9deab@rorschach.local.home> (raw)
In-Reply-To: <20221101064146.69551-1-lihuafei1@huawei.com>

On Tue, 1 Nov 2022 14:41:46 +0800
Li Huafei <lihuafei1@huawei.com> wrote:


> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index fbf2543111c0..4219cc2a04a6 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -3030,13 +3030,16 @@ int ftrace_shutdown(struct ftrace_ops *ops, int command)
>  
>  	if (!command || !ftrace_enabled) {

ftrace_enabled is seldom not set. I don't think we even need to check
it. It's just the value of /proc/sys/kernel/ftrace_enabled, where most
people don't even know that file exists. I do want to get rid of it one
day too. So let's not optimize for it.

>  		/*
> -		 * If these are dynamic or per_cpu ops, they still
> -		 * need their data freed. Since, function tracing is
> -		 * not currently active, we can just free them
> -		 * without synchronizing all CPUs.
> +		 * If these are dynamic, they still need their data freed. If
> +		 * function tracing is currently active, we neet to synchronize
> +		 * all CPUs before we can release them.
>  		 */
> -		if (ops->flags & FTRACE_OPS_FL_DYNAMIC)
> +		if (ops->flags & FTRACE_OPS_FL_DYNAMIC) {
> +			if (ftrace_enabled)
> +				goto sync_rcu;
> +
>  			goto free_ops;

Change the above just to "goto out;"

> +		}
>  
>  		return 0;
>  	}
> @@ -3083,6 +3086,7 @@ int ftrace_shutdown(struct ftrace_ops *ops, int command)
>  	 * ops.
>  	 */

Add here:

 out:

>  	if (ops->flags & FTRACE_OPS_FL_DYNAMIC) {
> + sync_rcu:
>  		/*
>  		 * We need to do a hard force of sched synchronization.
>  		 * This is because we use preempt_disable() to do RCU, but

And get rid of the labels in the if block.

Thanks!

-- Steve

  parent reply	other threads:[~2022-11-02 22:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-01  6:41 [PATCH] ftrace: Fix use-after-free for dynamic ftrace_ops Li Huafei
2022-11-01 14:07 ` Masami Hiramatsu
2022-11-02  2:53   ` Li Huafei
2022-11-02  4:43   ` Steven Rostedt
2022-11-02 23:59   ` Steven Rostedt
2022-11-02 22:53 ` Steven Rostedt [this message]
2022-11-03  2:06   ` Li Huafei

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=20221102185348.40f9deab@rorschach.local.home \
    --to=rostedt@goodmis.org \
    --cc=lihuafei1@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mhiramat@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.