linux-kernel - Re: [PATCH 2.6.20-rc1 00/10] Kernel memory leak detector 0.13

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 17 Dec 2006 11:58:49 +0000
From:	"Catalin Marinas" <catalin.marinas@...il.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.20-rc1 00/10] Kernel memory leak detector 0.13

On 17/12/06, Ingo Molnar <mingo@...e.hu> wrote:
> one more thing: after bootup i need to access the /debug/memleak file
> twice to get any output from it - is that normal? The first 'cat
> /debug/memleak' gives no output (but there's the usual scanning delay,
> so memleak does do its work).

Yes, this is normal. Especially on SMP, I get some transient reports,
probably caused by pointers hold in registers (even more visible on
ARM due to the bigger number of registers per CPU). Reporting a leak
only if it was seen at least once before greatly reduces the false
positives (this is configurable as well but I'll drop the
configuration option). Without this, you could see that, at every
scan, the reported pointers are different.

Some people testing kmemleak used to read the /debug/memleak file
periodically from a script and this wasn't noticeable. It would be
even better if, as you suggested, I schedule a periodic memory
scanning.

-- 
Catalin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/