linux-kernel - Re: Leaks in trace reported by kmemleak

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: <1255953605.31096.26.camel@pc1117.cambridge.arm.com>
Date:	Mon, 19 Oct 2009 13:00:05 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Zdenek Kabelac <zdenek.kabelac@...il.com>
Cc:	Li Zefan <lizf@...fujitsu.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: Leaks in trace reported by kmemleak

On Mon, 2009-10-19 at 11:15 +0200, Zdenek Kabelac wrote:
> 2009/10/16 Catalin Marinas <catalin.marinas@....com>:
> > On Fri, 2009-10-16 at 17:07 +0200, Zdenek Kabelac wrote:
> >> So I've tested this modified version and it gives much better result
> >> with respect to amount of leaked objects
> >
> > BTW, I created this tree with kmemleak patches to be pushed upstream:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/kmemleak.git
> >
> > It would be easier to test.
> 
> Yes this branch worked well - and there were no leaks  from i915 or
> kvm modules for trace.
> 
> What is however interesting is the false positive leak for
> dma_debug_init(). Which is sometimes listed and sometimes not - the
> memory is allocated just once in the code during boot, so it's strange
> that pointers to that area are sometimes out of kmemleak scan.

I updated the tree above with another patch which lists where an object
is referred from. So when you get a leak reported and it later
disappears, you can use:

echo dump=0x... > /sys/kernel/debug/kmemleak

and in syslog you can find information about the previously reported
object and where it is referred from (if it is no longer reported as a
leak). I'm not sure whether this option would be useful for anything
other than debugging kmemleak. I still aim on getting to near 0 false
positives.

Anyway, trying this new patch on the debug_objects, when no longer
reported they are referred from obj_hash. My opinion is that they were
moved to obj_hash during the kmemleak scanning but after kmemleak
finished scanning the data section, hence they couldn't be found.

I hoped that not reporting object allocated within the last 5s would
avoid such problems but there are places like debug_objects for which it
doesn't work as the objects were reported earlier.

A workaround I had in the past was to not report an object unless it was
found as a leak in two consecutive scans. I should probably reinstate
this feature (could be optimised to use a second prio_tree containing
only objects found as leaks).

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