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] [day] [month] [year] [list]

Message-ID: <1317030406.2557.21.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Date:	Mon, 26 Sep 2011 11:46:46 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Huajun Li <huajun.li.lee@...il.com>
Cc:	David Miller <davem@...emloft.net>, netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/2] net: Disable false positive memory leak report

Le lundi 26 septembre 2011 à 16:42 +0800, Huajun Li a écrit :
> Eric, thanks for your response. :)
> 
> 2011/9/26 Eric Dumazet <eric.dumazet@...il.com>:

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

But this interface should be only used in very specific situations, not
for transient kmemleak reports.

(When the pointer to allocated block is not stored in memory, or only
stored in the object itself : A detached area of memory)

AFAIK, its almost never used :

# git grep kmemleak_not_leak
Documentation/kmemleak.txt:kmemleak_not_leak     - mark an object as not a leak
Documentation/kmemleak.txt:kmemleak_not_leak function. The kmemleak_ignore could also be used if
arch/sparc/kernel/irq_64.c:     kmemleak_not_leak(bucket);
fs/block_dev.c: kmemleak_not_leak(bd_mnt);
fs/nfs/dir.c:   kmemleak_not_leak(string->name);
include/linux/kmemleak.h:extern void kmemleak_not_leak(const void *ptr) __ref;
include/linux/kmemleak.h:static inline void kmemleak_not_leak(const void *ptr)
kernel/module.c:        kmemleak_not_leak(ptr);
mm/kmemleak.c: * kmemleak_not_leak - mark an allocated object as false positive
mm/kmemleak.c:void __ref kmemleak_not_leak(const void *ptr)
mm/kmemleak.c:EXPORT_SYMBOL(kmemleak_not_leak);
mm/kmemleak.c:                  kmemleak_not_leak(log->ptr);
mm/page_cgroup.c:       kmemleak_not_leak(base);

percpu variables are not specific these days, and kmemleak definitely
knows about them.

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

We are not going to add patches to work around a core (kmemleak) issue,
especially without kmemleak maintainer feedback.

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