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);
prev parent 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®