Re: [PATCH 00/14] Kernel memory leak detector

Re: [PATCH 00/14] Kernel memory leak detector

[Andrew Morton]

On Fri, 19 Dec 2008 18:12:56 +0000
Catalin Marinas <catalin.marinas@arm.com> wrote:

> A new kmemleak version is available. Thanks to all who reviewed the code
> and provided feedback.

There are a largeish number of trivialish rejects against all the
pending 2.6.29 code.  Fairly easily fixed.

I merge these patches into my tree, but I'd like to drop them again ;)

> Kmemleak can also be found on this git tree:
> 
> git://linux-arm.org/linux-2.6.git kmemleak

Please prepare and maintain a tree for inclusion in linux-next shortly
after 2.6.29-rc1 is released.




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?


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?

Re: [PATCH 00/14] Kernel memory leak detector

[Catalin Marinas]

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