lkml.org 
[lkml]   [2006]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2.6.17-rc4 1/6] Base support for kmemleak
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
-
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/

\
 
 \ /
  Last update: 2006-05-26 23:52    [W:0.619 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site