linux-kernel - Re: kmemleak reports

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: <1247654787.10407.39.camel@pc1117.cambridge.arm.com>
Date:	Wed, 15 Jul 2009 11:46:27 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Kevin Winchester <kjwinchester@...il.com>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: kmemleak reports

On Tue, 2009-07-14 at 20:28 -0300, Kevin Winchester wrote:
> I have noticed a few kmemleak reports being sent to LKML in the last
> few days, and I could chime in with mine, if you wish:
> 
>     kmemleak: 97 new suspected memory leaks (see /sys/kernel/debug/kmemleak)

That's not unlikely, though several of reports may come from a single
place (a user-space script could be used to group them together).

> The entries are for X, ntpdate, scsi_scan_2, softirq, swapper, in case
> there's anything surprising in there.

As I mentioned in the past, you can run a few "echo scan
> /sys/kernel/debug/kmemleak" to see if any of them disappear.

> However, I was thinking that you might soon start getting too many
> reports to process.  I wonder if there might be some way that you
> could have a similar facility to kerneloops that would automatically
> register leak reports to a website where they could be organized and
> ranked by number of occurrences.  Are the individual leaks reported in
> such at way that would allow them to be grouped like that?

The leaks are reported in the order they were allocated and this makes
it easier to debug (since an early leak may trigger subsequent reports
on pointers it contains since it isn't scanned).

My hope is that once the initial leaks are fixed, there will be less in
the future and could be easily linked to recent commits (which is not
always the case now).

I don't have the time to set up something like kerneloops but I'm happy
to manually log them somewhere (like bugzilla.kernel.org).
Alternatively, kerneloops.org could detect kmemleak reports on the list
and log them.

> If a kerneloops-style setup is not desirable/feasible, would you be
> able to send me a walkthrough for how you go about tracking down one
> of these leaks?  Then I might be able to help out by investigating a
> few of my own.

First, make sure you use -rc3 as it has several kmemleak fixes. On
x86_64, there is another patch I posted for moving the _edata in
vmlinux.lds.S to be able to scan the whole .data section.

I gave some hints in this message - http://lkml.org/lkml/2009/7/14/72.
I'll also update the Documentation/kmemleak.txt file with such
information in the next few days.

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