Messages in this thread | | | Date | Fri, 26 May 2006 22:49:57 +0100 | From | Catalin Marinas <> | Subject | Re: [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/
| |