From: Catalin Marinas <catalin.marinas@arm•com>
To: Andrew Morton <akpm@linux-foundation•org>
Cc: linux-kernel@vger•kernel.org, linux-next@vger•kernel.org
Subject: Re: [PATCH 00/14] Kernel memory leak detector
Date: Tue, 30 Dec 2008 11:43:50 +0000 [thread overview]
Message-ID: <1230637430.3909.38.camel@pc1117.cambridge.arm.com> (raw)
In-Reply-To: <20081229162310.705a25fe.akpm@linux-foundation.org>
On Mon, 2008-12-29 at 16:23 -0800, Andrew Morton wrote:
> What is the track record of this code? Has it found many leaks? Do
> we expect that it will find sufficient leaks of sufficient importance
> to justify kmemleak's inclusion and maintenance?
It found a few leaks not found by static code analysis (not many though)
but I mainly tested it on small embedded systems. I think it may be
better to include it in the -mm tree for a while so that more people
test it before deciding whether to merge it into mainline.
FYI, here are some past reports:
http://lkml.org/lkml/2006/5/28/37
http://lkml.org/lkml/2006/7/10/370
http://lkml.org/lkml/2006/8/10/207
http://lkml.org/lkml/2006/8/12/11
http://lkml.org/lkml/2006/8/19/44
http://lkml.org/lkml/2006/12/9/178
http://lkml.org/lkml/2006/12/9/176
http://lkml.org/lkml/2007/3/8/222
http://lkml.org/lkml/2008/11/19/204
> I'm a little doubtful personally. We often fix leaks, and they are
> almost always things which nobody noticed at runtime, and which were
> found by code inspection or source-code checking tools. And they're
> usually leaks which nobody would care about much anyway?
I'm a bit biased to comment on the usefulness of kmemleak :-). Anyway,
AFAIK static code checking tools (like coverity) are good for relatively
simple things like not freeing on an error return path (maybe they can
go further across multiple files, I haven't tried it). I doubt such
tools can catch leaks caused by incorrect reference counting or very
complex code. OTOH, kmemleak doesn't report a leak unless it occurred,
so static and dynamic checking tools are rather complementary.
Now, as long as the code is correctly written and with additional static
checking, kmemleak shouldn't find a significant number of bugs. However,
some (earlier) bugs mentioned above were causing tens of (small) leaks
in a few minutes. They may have become visible after days of running but
it's much easier to catch and fix them early.
You can't really tell whether a leak is serious or not until you check
the code. A leak doesn't necessarily mean that you can no longer reuse a
block of memory but the code possibly frees a different one still in use
by other parts of the kernel (e.g. the last report mentioned above).
--
Catalin
prev parent reply other threads:[~2008-12-30 11:44 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20081219181255.7778.52219.stgit@pc1117.cambridge.arm.com>
2008-12-30 0:23 ` [PATCH 00/14] Kernel memory leak detector Andrew Morton
2008-12-30 11:43 ` Catalin Marinas [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=1230637430.3909.38.camel@pc1117.cambridge.arm.com \
--to=catalin.marinas@arm$(echo .)com \
--cc=akpm@linux-foundation$(echo .)org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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