Messages in this thread | | | Subject | Re: [PATCH 00/14] Kernel memory leak detector | From | Catalin Marinas <> | Date | Tue, 30 Dec 2008 11:43:50 +0000 |
| |
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
| |