Re: [PATCH 2.6.17-rc6 7/9] Remove some of the kmemleak false positives

[Ingo Molnar <mingo@elte.hu>]

* Pekka J Enberg <penberg@cs.Helsinki.FI> 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