netdev - Re: [PATCH 1/2] net: Disable false positive memory leak report

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]

Message-ID: <CA+v9cxZk_bsxrnn8zS-viH-0Wozz-T0XiFB0AE1fOOKqjcQ2ZQ@mail.gmail.com>
Date:	Mon, 26 Sep 2011 16:42:46 +0800
From:	Huajun Li <huajun.li.lee@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	Huajun Li <huajun.li.lee@...il.com>
Subject: Re: [PATCH 1/2] net: Disable false positive memory leak report

Eric, thanks for your response. :)

2011/9/26 Eric Dumazet <eric.dumazet@...il.com>:
> Le samedi 24 septembre 2011 à 23:57 +0800, Huajun Li a écrit :
>> Memory leak detector reports following false positive memory leak, the
>> patch disables it.
>>
>> 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
>>
>>
>> Signed-off-by: Huajun Li <huajun.li.lee@...il.com>
>> ---
>>  net/core/flow.c |    7 +++++++
>>  1 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/core/flow.c b/net/core/flow.c
>> index 555a456..ba3e617 100644
>> --- a/net/core/flow.c
>> +++ b/net/core/flow.c
>> @@ -365,6 +365,13 @@ static int __cpuinit
>> flow_cache_cpu_prepare(struct flow_cache *fc, int cpu)
>>
>>       if (!fcp->hash_table) {
>>               fcp->hash_table = kzalloc_node(sz, GFP_KERNEL, cpu_to_node(cpu));
>> +             /*
>> +              * Avoid a kmemleak false positive. The pointer to this block
>> +              * is refferenced by per-CPU varaible, here just mark it as not
>> +              * being a leak.
>> +              */
>> +             kmemleak_not_leak(fcp->hash_table);
>> +
>>               if (!fcp->hash_table) {
>>                       pr_err("NET: failed to allocate flow cache sz %zu\n", sz);
>>                       return -ENOMEM;
>
> This makes no sense to me.
>
> per-cpu variables are taken into account by kmemleak.
>

Yes, I think so.

> If not, you should report this problem to kmemleak maintainer.
>

To deal with false positives/negatives, in kmemleak document, it says:
...
The false positives are objects wrongly reported as being memory leaks
(orphan). For objects known not to be leaks, kmemleak provides the
kmemleak_not_leak function. The kmemleak_ignore could also be used if
the memory block is known not to contain other pointers and it will no
longer be scanned.
...

For some scenarios, _maybe_ it's hard for kmemleak to give report
exactly, and I think it is known issue for the maintainers, so hope
there will be a powerful version soon. :)
However, before the new version of kmemleak(if there is new version)
comes, is it possible to disable this false positive report as other
components? You know, other guys maybe also check the code once they
meet the report again just like me.
--
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