From: Carsten Emde <C.Emde@osadl.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Nicholas Mc Guire <der.herr@hofr.at>,
Thomas Gleixner <tglx@linutronix.de>,
RT-users <linux-rt-users@vger.kernel.org>
Subject: Re: [PATCH 1/1] tracing/latency_hist Fix memory leak
Date: Fri, 14 Feb 2014 21:28:39 +0100 [thread overview]
Message-ID: <52FE7C77.7020408@osadl.org> (raw)
In-Reply-To: <52FE75A9.6050305@linutronix.de>
On 02/14/2014 08:59 PM, Sebastian Andrzej Siewior wrote:
> On 02/14/2014 06:26 PM, Carsten Emde wrote:
>> The index_ptr memory that is allocated when printout is started
>> currently is only returned when the printout is stopped
>> prematurely. It is not returned when the printout regularly
>> finishes. Fix this memory leak.
>>
>> Signed-off-by: Carsten Emde <C.Emde@osadl.org>
>>
>> Index: linux-3.12.10-rt15-somedebug/kernel/trace/latency_hist.c
>> ===================================================================
>> --- linux-3.12.10-rt15-somedebug.orig/kernel/trace/latency_hist.c
>> +++ linux-3.12.10-rt15-somedebug/kernel/trace/latency_hist.c
>> @@ -313,6 +313,7 @@ static void *l_next(struct seq_file *m,
>>
>> if (++*pos >= MAX_ENTRY_NUM) {
>> atomic_inc(&my_hist->hist_mode);
>> + kfree(p);
>> return NULL;
>> }
>> *index_ptr = *pos;
>
> Sure on that? If I look at seq_read() I see that there is that ->stop()
> is always called after ->start() / ->next() before returning to caller.
> Based on this I would say that this patach will introduce a double free
> of p.
Some of the farm systems enable different levels of run time debug
features including kmemleak in two of them. These two machines regularly
crashed with kmemleak alloc overflow, because the system detected so
many memleaks that there was no more memory available to store all of
them. Since the objects were so small, the leak was not measurable in
terms of memory exhaustion. I then investigated the kmemleak objects,
and they clearly pointed to the index_ptr memory. This was the only
place I found, and kmemleak no longer complaint or crashed after
inserting this kfree(). I then patched the other farm systems some time
ago where it never never did any harm. I needed to find a solution to
the kmemleak machines, since otherwise I wouldn't have a usable tool to
search for other memleaks. But I know that I should have done better. So
please drop this patch and wait, until I find some time to more
carefully analyze the entire situation.
-Carsten.
prev parent reply other threads:[~2014-02-14 20:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-14 17:26 [PATCH 0/1] Fix a small memory leak in latency histograms Carsten Emde
2014-02-14 17:26 ` [PATCH 1/1] tracing/latency_hist Fix memory leak Carsten Emde
2014-02-14 19:59 ` Sebastian Andrzej Siewior
2014-02-14 20:28 ` Carsten Emde [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=52FE7C77.7020408@osadl.org \
--to=c.emde@osadl.org \
--cc=bigeasy@linutronix.de \
--cc=der.herr@hofr.at \
--cc=linux-rt-users@vger.kernel.org \
--cc=tglx@linutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).