Re: [for-next][PATCH 13/29] tracing: No need to free iter->trace in fail path of tracing_open_pipe()

[Steven Rostedt]

Here's the new patch change log:

>From e7f0c424d0806b05d6f47be9f202b037eb701707 Mon Sep 17 00:00:00 2001
From: "zhangyi (F)" 
Date: Wed, 13 Feb 2019 20:29:06 +0800
Subject: [PATCH] tracing: Do not free iter->trace in fail path of
 tracing_open_pipe()

Commit d716ff71dd12 ("tracing: Remove taking of trace_types_lock in
pipe files") use the current tracer instead of the copy in
tracing_open_pipe(), but it forget to remove the freeing sentence in
the error path.

There's an error path that can call kfree(iter->trace) after the iter->trace
was assigned to tr->current_trace, which would be bad to free.

Link: 
http://lkml.kernel.org/r/1550060946-45984-1-git-send-email-yi.zh...@huawei.com

Cc: sta...@vger.kernel.org
Fixes: d716ff71dd12 ("tracing: Remove taking of trace_types_lock in pipe files")
Signed-off-by: zhangyi (F) 
Signed-off-by: Steven Rostedt (VMware) 
---
 kernel/trace/trace.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index c521b7347482..b583ff7656bb 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -5624,7 +5624,6 @@ static int tracing_open_pipe(struct inode *inode, struct 
file *filp)
return ret;
 
 fail:
-   kfree(iter->trace);
kfree(iter);
__trace_array_put(tr);
mutex_unlock(_types_lock);
-- 
2.20.1

Re: [for-next][PATCH 13/29] tracing: No need to free iter->trace in fail path of tracing_open_pipe()

[Steven Rostedt]

On Wed, 20 Feb 2019 13:37:50 -0500
Steven Rostedt  wrote:

> From: "zhangyi (F)" 
> 
> Commit d716ff71dd12 ("tracing: Remove taking of trace_types_lock in
> pipe files") use the current tracer instead of the copy in
> tracing_open_pipe(), but it forget to remove the freeing sentence in
> the error path.
> 
> [ Note, this is harmless because kfree(NULL) is allowed and iter is
>   allocated with kzalloc() making iter->trace = NULL -- S. Rostedt ]

Bah, I forgot to update this. I haven't pushed to linux-next yet.

As Zhangyi replied, this is a real issue. I just wished the real issue
was explained in the change log.

I'm going to rebase this to update the change log (no code changes, so
no need to run the tests again), and also, I'll add a Cc stable. No
point in sending this out as a separate patch either, because the merge
window is going to open soon.

-- Steve


> 
> Link: 
> http://lkml.kernel.org/r/1550060946-45984-1-git-send-email-yi.zh...@huawei.com
> 
> Fixes: d716ff71dd12 ("tracing: Remove taking of trace_types_lock in pipe 
> files")
> Signed-off-by: zhangyi (F) 
> Signed-off-by: Steven Rostedt (VMware) 
> ---
>  kernel/trace/trace.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index c521b7347482..b583ff7656bb 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -5624,7 +5624,6 @@ static int tracing_open_pipe(struct inode *inode, 
> struct file *filp)
>   return ret;
>  
>  fail:
> - kfree(iter->trace);
>   kfree(iter);
>   __trace_array_put(tr);
>   mutex_unlock(_types_lock);