* Pekka J Enberg <[email protected]> wrote:
> On Mon, 12 Jun 2006, Catalin Marinas wrote:
> > I thought about this as well (I think that's how Valgrind works) but
> > it would increase the chances of missing real leaks.
>
> Yeah but that's far better than adding bunch of 'not a leak'
> annotations around the kernel which is very impractical to maintain.
> I would like to see your leak detector in the kernel so we can finally
> get rid of all those per-subsystem magic allocators. This patch,
> however, is unacceptable for inclusion IMHO.
While it's always good to reduce the amount of false positives, i dont
think it's unacceptable for inclusion right now. A few dozen annotations
out of 7000+ allocation call sites isnt a big maintainance problem - and
the benefits of automatic leak-checking are really huge. The impact only
appears to be large because the patch is trying to cover an initial 7+
million lines of codebase. The followup per-kernel-release overhead will
be minimal, and will be offset by the quality increase of the kernel and
by the productivity increase that comes due to developers not having to
do long searches for kernel memory leaks. The debugging cost of a single
leak found can far outweigh the cost of 10 annotations (or more).
What i'd like to see though are clear explanations about why an
allocation is not considered a leak, in terms of comments added to the
code. That will also help us reduce the number of annotations later on.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
