Re: [PATCH 2.6.28-rc5 00/11] Kernel memory leak detector (updated)

[Ingo Molnar <mingo@elte.hu>]

* Catalin Marinas <catalin.marinas@arm.com> wrote:

> The main changes (for those who remember the original features):
> 
> - it now uses a priority search tree to make it easier for looking up
>   intervals rather than just fixed values (the initial implementation
>   was with radix tree and changed to hash array because of
>   kmem_cache_alloc calls in the former)
> - internal memory allocator to avoid recursive calls into
>   kmemleak. This is a simple lock-free, per-cpu allocator using
>   pages. The number of pages allocated is bounded, though there could
>   be (very unlikely) situations on SMP systems where page occupation
>   isn't optimal
> - support for all three memory allocators - slab, slob and slub
> - finer-grained locking - there is no global lock held during memory
>   scanning
> - more information reported for leaked objects - current task's
>   command line and pid, jiffies and the stack trace

these are very nice improvements! In particular the sharp reduction in 
false positives and annotations is encouraging.

I'd like to try it in the -tip automated testing setup, provided the 
few details i just commented on are solved, and provided that these 
things are addressed as well:

> Things still to be done:
> 
> - kernel thread to scan and report leaked objects periodically
>   (currently done only when reading the /sys/kernel/debug/memleak
>   file)
> - run-time and boot-time configuration like task stacks scanning,
>   disabling kmemleak, enabling/disabling the automatic scanning

the .config driven automatic "report currently known/suspected leaks 
60 seconds after bootup" feature would be nice to have. Should be 
fairly easy to add, right? Otherwise i'd have no good way of getting a 
leak report out of it, in an automated way.

	Ingo