netdev - Re: Question about memory leak detector giving false positive report for net/core/flow.c

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, 26 Sep 2011 18:32:54 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Huajun Li <huajun.li.lee@...il.com>
Cc:	Catalin Marinas <catalin.marinas@....com>, linux-mm@...ck.org,
	netdev <netdev@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Tejun Heo <tj@...nel.org>,
	Christoph Lameter <cl@...ux-foundation.org>
Subject: Re: Question about memory leak detector giving false positive
 report for net/core/flow.c

Le lundi 26 septembre 2011 à 23:17 +0800, Huajun Li a écrit :
> Memory leak detector gives following memory leak report, it seems the
> report is triggered by net/core/flow.c, but actually, it should be a
> false positive report.
> So, is there any idea from kmemleak side to fix/disable this false
> positive report like this?
> Yes, kmemleak_not_leak(...) could disable it, but is it suitable for this case ?
> 
> BTW, I wrote a simple test code to emulate net/core/flow.c behavior at
> this stage which triggers the report, and it could also make kmemleak
> give similar report, please check below test code:
> 
> kernel version:
> #uname -a
> Linux 3.1.0-rc7 #22 SMP Tue Sep 26 05:43:01 CST 2011 x86_64 x86_64
> x86_64 GNU/Linux
> 
> memory leak report:
> -------------------------------------------------------------------------------------------
> unreferenced object 0xffff880073a70000 (size 8192):
>   comm "swapper", pid 1, jiffies 4294937832 (age 445.740s)
>   hex dump (first 32 bytes):
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>   backtrace:
>     [<ffffffff8124db64>] create_object+0x144/0x360
>     [<ffffffff8191192e>] kmemleak_alloc+0x7e/0x110
>     [<ffffffff81235b26>] __kmalloc_node+0x156/0x3a0
>     [<ffffffff81935512>] flow_cache_cpu_prepare.clone.1+0x58/0xc0
>     [<ffffffff8214c361>] flow_cache_init_global+0xb6/0x1af
>     [<ffffffff8100225d>] do_one_initcall+0x4d/0x260
>     [<ffffffff820ec2e9>] kernel_init+0x161/0x23a
>     [<ffffffff8194ab04>] kernel_thread_helper+0x4/0x10
>     [<ffffffffffffffff>] 0xffffffffffffffff
> unreferenced object 0xffff880073a74290 (size 8192):
>   comm "swapper", pid 1, jiffies 4294937832 (age 445.740s)
>   hex dump (first 32 bytes):
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>   backtrace:
>     [<ffffffff8124db64>] create_object+0x144/0x360
>     [<ffffffff8191192e>] kmemleak_alloc+0x7e/0x110
>     [<ffffffff81235b26>] __kmalloc_node+0x156/0x3a0
>     [<ffffffff81935512>] flow_cache_cpu_prepare.clone.1+0x58/0xc0
>     [<ffffffff8214c361>] flow_cache_init_global+0xb6/0x1af
>     [<ffffffff8100225d>] do_one_initcall+0x4d/0x260
>     [<ffffffff820ec2e9>] kernel_init+0x161/0x23a
>     [<ffffffff8194ab04>] kernel_thread_helper+0x4/0x10
>     [<ffffffffffffffff>] 0xffffffffffffffff
> 
> 
> 
> Simple test code to reproduce a similar report:
> -----------------------------------------------------------------------------------------
> MODULE_LICENSE("GPL");
> 
> struct test {
>         int *pt;


	char spaceholder[30000];

> };
> 
> static struct test __percpu *percpu;
> 
> static int __init test_init(void)
> {
>         int i;
> 
>         percpu = alloc_percpu(struct test);
>         if (!percpu)
>                 return -ENOMEM;
> 
>         for_each_online_cpu(i) {
>                 struct test *p = per_cpu_ptr(percpu, i);
>                 p->pt = kmalloc(sizeof(int), GFP_KERNEL);
>         }
> 
>         return 0;
> }
> 
> static void __exit test_exit(void)
> {
>         int i;
> 
>         for_each_possible_cpu(i) {
>                 struct test *p = per_cpu_ptr(percpu, i);
>                 if (p->pt)
>                         kfree(p->pt);
>         }
> 
>         if (percpu)
>                 free_percpu(percpu);
> }
> module_init(test_init);
> module_exit(test_exit);


CC lkml and percpu maintainers (Tejun Heo & Christoph Lameter ) as well

AFAIK this false positive only occurs if percpu data is allocated
outside of embedded pcu space. 

 (grep pcpu_get_vm_areas /proc/vmallocinfo)

I suspect this is a percpu/kmemleak cooperation problem (a missing
kmemleak_alloc() ?)

I am pretty sure kmemleak_not_leak() is not the right answer to this
problem.



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html