linux-kernel - Re: How to analyze kmemleak message?

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:	Mon, 23 Feb 2009 12:20:34 +0000
From:	Catalin Marinas <catalin.marinas@....com>
To:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:	penberg@...helsinki.fi, linux-kernel@...r.kernel.org
Subject: Re: How to analyze kmemleak message?

On Mon, 2009-02-23 at 20:29 +0900, Tetsuo Handa wrote:
> Catalin Marinas wrote:
> > This object can no longer be found to be referred by other objects or
> > from the data section, hence it is assumed to be a leak (it could, as
> > well, be a false positive, transient or not).
> Kmemleak scans all data section for addresses returned by kmalloc() etc.
> 
>   void *p1;
>   
>   void foo(void)
>   {
>       void *p2 = kmalloc(1, GFP_KERNEL);
>       p1 = kmalloc(1, GFP_KERNEL);
>   }
> 
> "p1" will be reported by default.

p1 won't be reported as a leak because it is a global variable and the
data section is scanned.

> To report "p2", we need to write "stack=on" to /sys/kernel/debug/kmemleak .

It's the opposite - p2 will be reported as leak by default (stack=off)
unless you enable the stack scanning (stack=on). Note that in the above
case, even if you scan the stacks, once foo() finished the data on the
stack may be overridden by other function calls and p2 will be reported
as a leak.

> > Basically, you need check
> > where the pointer returned by kmalloc/kmem_cache_alloc etc. should be
> > stored and whether it can still be referred from that place (or a
> > different one) later.
> > 
> > Kmemleak tries to avoid the reporting of transient leaks by only
> > reporting objects with a life time of more than 5 seconds.
> kjournald's commit interval (default to 5 sec?) + a few seconds
> might be better. (No reason. Just my feeling.)

I don't think it will make any difference but I may try to increase this
if I get too many transient leaks reported.

> I have a question. My module uses kmalloc(PATH_MAX, GFP_KERNEL) which
> won't be released by kfree(). I count up how many bytes are allocated but
> I don't want kmemleak to report such memory as memory leaks.
> Can I do so by
> 
>   void bar(void)
>   {
>       static void *p;
>       if (!p) {
>           p = kmalloc(PATH_MAX, GFP_KERNEL);
>           kmemleak_not_leak(p);
>       }
>       ...
>   }
> 
> (or kmemleak_ignore() (which one to use and how to use))?

I don't think you need to do anything here. Since p is a static local
variable, isn't it placed in a data section somewhere (and automatically
scanned by kmemleak)?

FYI, kmemleak_ignore() is meant for objects which aren't leaks and which
don't need to be scanned for pointers to other objects (i.e. the code
sections in a module). kmemleak_not_leak() is meant for objects which
are reported as leaks but are known not to be (i.e. the pointer is
stored in a place that kmemleak doesn't scan or the pointer value is
modified before storing or reading) and they should be scanned for
pointers to other objects.

-- 
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/