mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: "Lai Jiangshan" <laijs@cn.fujitsu.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Frédéric Weisbecker" <fweisbec@gmail.com>
Date: Tue, 24 Mar 2009 09:11:47 -0400 (EDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.0903240909320.22830@gandalf.stny.rr.com> (raw)
In-Reply-To: <20090324112050.GC6386@elte.hu>




On Tue, 24 Mar 2009, Ingo Molnar wrote:

> 
> * Lai Jiangshan <laijs@cn.fujitsu.com> wrote:
> > >> Steven Rostedt (1):
> > >>       tracing: fix memory leak in trace_stat

[...]

> > 
> > Hi, Ingo
> > 
> > I found this patch is not in the tip tree.
> 
> It was tied to the function profiler which is still being debated. 
> Steve, mind re-anchoring that commit?

Hi Ingo,

Just created a branch from your latest tracing/ftrace and cherry picked
this change. I'll rebase my tip/tracing/ftrace branch on your changes
as soon as I see it in. I have more changes for the function profiler that
I think will make it worth having. Soon to be announced.

Please pull the latest tip/tracing/ftrace-1 tree, which can be found at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
tip/tracing/ftrace-1


Steven Rostedt (1):
      tracing: fix memory leak in trace_stat

----
 kernel/trace/trace_stat.c |   23 +++++++++++++----------
 1 files changed, 13 insertions(+), 10 deletions(-)
---------------------------
commit 098335215a4921a8a54193829eaed602dca24df5
Author: Steven Rostedt <srostedt@redhat.com>
Date:   Sat Mar 21 02:44:50 2009 -0400

    tracing: fix memory leak in trace_stat
    
    If the function profiler does not have any items recorded and one were
    to cat the function stat file, the kernel would take a BUG with a NULL
    pointer dereference.
    
    Looking further into this, I found that returning NULL from stat_start
    did not stop the stat logic, and would later call stat_next. This breaks
    from the way seq_file works, so I looked into fixing the stat code.
    
    This is where I noticed that the last next_entry is never freed.
    It is allocated, and if the stat_next returns NULL, the code breaks out
    of the loop, unlocks the mutex and exits. We never link the next_entry
    nor do we free it. Thus it is a real memory leak.
    
    This patch rearranges the code a bit to not only fix the memory leak,
    but also to act more like seq_file where nothing is printed if there
    is nothing to print. That is, stat_start returns NULL.
    
    Signed-off-by: Steven Rostedt <srostedt@redhat.com>

diff --git a/kernel/trace/trace_stat.c b/kernel/trace/trace_stat.c
index 39310e3..f71b85b 100644
--- a/kernel/trace/trace_stat.c
+++ b/kernel/trace/trace_stat.c
@@ -75,7 +75,7 @@ static int stat_seq_init(struct tracer_stat_session *session)
 {
 	struct trace_stat_list *iter_entry, *new_entry;
 	struct tracer_stat *ts = session->ts;
-	void *prev_stat;
+	void *stat;
 	int ret = 0;
 	int i;
 
@@ -85,6 +85,10 @@ static int stat_seq_init(struct tracer_stat_session *session)
 	if (!ts->stat_cmp)
 		ts->stat_cmp = dummy_cmp;
 
+	stat = ts->stat_start();
+	if (!stat)
+		goto exit;
+
 	/*
 	 * The first entry. Actually this is the second, but the first
 	 * one (the stat_list head) is pointless.
@@ -99,14 +103,19 @@ static int stat_seq_init(struct tracer_stat_session *session)
 
 	list_add(&new_entry->list, &session->stat_list);
 
-	new_entry->stat = ts->stat_start();
-	prev_stat = new_entry->stat;
+	new_entry->stat = stat;
 
 	/*
 	 * Iterate over the tracer stat entries and store them in a sorted
 	 * list.
 	 */
 	for (i = 1; ; i++) {
+		stat = ts->stat_next(stat, i);
+
+		/* End of insertion */
+		if (!stat)
+			break;
+
 		new_entry = kmalloc(sizeof(struct trace_stat_list), GFP_KERNEL);
 		if (!new_entry) {
 			ret = -ENOMEM;
@@ -114,11 +123,7 @@ static int stat_seq_init(struct tracer_stat_session *session)
 		}
 
 		INIT_LIST_HEAD(&new_entry->list);
-		new_entry->stat = ts->stat_next(prev_stat, i);
-
-		/* End of insertion */
-		if (!new_entry->stat)
-			break;
+		new_entry->stat = stat;
 
 		list_for_each_entry(iter_entry, &session->stat_list, list) {
 
@@ -137,8 +142,6 @@ static int stat_seq_init(struct tracer_stat_session *session)
 				break;
 			}
 		}
-
-		prev_stat = new_entry->stat;
 	}
 exit:
 	mutex_unlock(&session->stat_mutex);

      reply	other threads:[~2009-03-24 13:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-21  6:54 [PATCH][GIT PULL] tracing: fix memory leak in trace_stat Steven Rostedt
2009-03-21  9:43 ` Ingo Molnar
2009-03-24  7:43   ` Lai Jiangshan
2009-03-24 11:20     ` Ingo Molnar
2009-03-24 13:11       ` Steven Rostedt [this message]

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=alpine.DEB.2.00.0903240909320.22830@gandalf.stny.rr.com \
    --to=rostedt@goodmis.org \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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

all inboxes | Powered by JetHome®