tracing: fix memory leak in trace_stat
authorSteven Rostedt <srostedt@redhat.com>
Sat, 21 Mar 2009 06:44:50 +0000 (02:44 -0400)
committerSteven Rostedt <srostedt@redhat.com>
Tue, 24 Mar 2009 13:07:35 +0000 (09:07 -0400)
commit098335215a4921a8a54193829eaed602dca24df5
tree86226d7e4229f00e467b5e6ed7f048a2061c3042
parent45b9560895b07a4a09d55d49235c984db512c5aa
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>
kernel/trace/trace_stat.c