Messages in this thread | | | Date | Mon, 12 Jun 2006 12:53:45 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 2.6.17-rc6 7/9] Remove some of the kmemleak false positives |
| |
* 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |