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




* Pekka J Enberg <penberg@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • Re: Size-128 slab leak
    ... > I have an annoying slab leak on my kernel. ... I lose about> 50Megs of memory to the leak. ... walks the objects in the size-4096 slab, printing out the calling address of whoever allocated that object. ... *dbg_redzone1(cachep, objp) = RED_ACTIVE; *dbg_redzone2= RED_ACTIVE;} ...
    (Linux-Kernel)
  • Re: [PATCH 10 of 20] ipath - support for userspace apps using core driver
    ... and tomorrow I'll try to see if I can work out the leak; ... it turns out that the BUG I mentioned was reported against ... the SLES10 2.6.16-rc6 kernel. ... suggestion from last week of just shooting nopage in the head, ...
    (Linux-Kernel)
  • Re: Finding memory leak
    ... Could only find two instances one allocating 14 bytes and the other 4096. ... The kernel network code is way beyond my knowledge and I cannot determine ... it is very very likely that the leak ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: 2.6.8-1.521 memory leak? (was: [...] FC1/i386 vs FC2/x86_64: [...] memory consumption?)
    ... leak occurs when trying to rebuild 2.6.8-1.521 kernels or kernel ... > It turns out that memory gets consumed and not returned back to the ... > VmallocChunk: 536869323 kB ...
    (Fedora)
  • Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4]
    ... > if there were a facility in the kernel to easily identify missed ... > interrupts on its own and he could not identify all those places. ... Note that an irqs-off condition is near impossible to 'leak' into ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)