* Re: [PATCH 00/14] Kernel memory leak detector
[not found] <20081219181255.7778.52219.stgit@pc1117.cambridge.arm.com>
@ 2008-12-30 0:23 ` Andrew Morton
2008-12-30 11:43 ` Catalin Marinas
0 siblings, 1 reply; 2+ messages in thread
From: Andrew Morton @ 2008-12-30 0:23 UTC (permalink / raw)
To: Catalin Marinas; +Cc: linux-kernel, linux-next
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?
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH 00/14] Kernel memory leak detector
2008-12-30 0:23 ` [PATCH 00/14] Kernel memory leak detector Andrew Morton
@ 2008-12-30 11:43 ` Catalin Marinas
0 siblings, 0 replies; 2+ messages in thread
From: Catalin Marinas @ 2008-12-30 11:43 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-next
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2008-12-30 11:44 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox