linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

      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).