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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
