Re: [PATCH 2.6.17-rc4 1/6] Base support for kmemleak

[Catalin Marinas <catalin.marinas@gmail.com>]

Hi Ingo,

Ingo Molnar wrote:
> * Catalin Marinas <catalin.marinas@gmail.com> wrote:
>>A problem I'm facing (also because I'm not familiar with the other 
>>architectures) is detecting the effective stack boundaries of the 
>>threads running or waiting in kernel mode. Scanning the whole stack 
>>(8K) hides some possible leaks (because of no longer used local 
>>variables) and not scanning the list at all can lead to false 
>>positives. I would need to investigate this a bit more.
> 
> i was thinking about this too, and i wanted to suggest a different 
> solution here: you could build a list of "temporary" objects that only 
> get registered with the memleak proper once a thread exits a system call 
> (or once a kernel thread goes back to its main loop). This means a 
> (lightweight) callback in the syscall exit (or irq exit) path. This way 
> you'd not have to scan kernel stacks at all, only .data and the objects 
> themselves.

That's an interesting approach. I'll first look at the level of false
positives without scanning the stacks at all.

> avoiding the scanning of the kernel stacks gets rid of some of the 
> biggest source of natural entropy. (they contain strings and all sorts 
> of other binary data that could accidentally match up with a kernel 
> pointer)

Indeed, there is a quite high rate of false negatives (undetected leaks)
in my tests, especially on SMP, when scanning the stacks. However, I
haven't got any false positive when not scanning them (on an embedded
platform). I think even the false positives in this case would be mainly
temporary (until a moment of relative calm, i.e. most tasks sleeping).

On SMP there can be another issue - pointers kept in registers only -
leading to false positives. Anyway, I think it's more important to have
a few (temporary) false positives rather than missing real memory leaks.

Catalin