linux-kernel - Re: Possible memory leak in net/wireless/scan.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]

Message-Id: <1247042784.6595.7.camel@pc1117.cambridge.arm.com>
Date:	Wed, 08 Jul 2009 09:46:24 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	linux-wireless@...r.kernel.org,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Possible memory leak in net/wireless/scan.c

On Wed, 2009-07-08 at 05:06 +0200, Johannes Berg wrote:
> On Tue, 2009-07-07 at 18:04 +0100, Catalin Marinas wrote:
> > Hi,
> > 
> > I'm investigating several kmemleak reports like the one below (it could
> > as well be a false positive but it needs more digging):
> 
> By the way, what kind of machine do you need for kmemleak to be
> feasible? I tried booting a kernel with it in kvm on my 2 ghz laptop,
> and that was completely unfeasible.

What do you mean by unfeasible?

There are some patches in my kmemleak branch which I'll push upstream
again (important ones are the renicing of the kmemleak thread and a few
more cond_resched calls):

http://www.linux-arm.org/git?p=linux-2.6.git;a=shortlog;h=kmemleak

There are 3 more patches under discussion to track the bootmem
allocations (which dropped the number of false positives to 0 on my
laptop).

Anyway, I run it from some ARM embedded systems at ~200MHz and 256MB of
RAM to dual core x86 at 2GHz with 3GB of RAM. I also ran it on quemu in
the past (but, well, in the embedded world I'm pretty used with
emulators taking 10 min to boot the kernel).

But it can slow things down since it tracks every memory allocation and
it needs to look up the pointer in an rb tree.

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