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

Catalin Marinas
2006-05-26T21:50:03Z

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