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

[Catalin Marinas <catalin.marinas@arm.com>]

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