linux-kernel - Re: kmemleak for MIPS

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]

Date:	Tue, 29 Mar 2011 12:50:54 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Maxin John <maxin.john@...il.com>
Cc:	Daniel Baluta <dbaluta@...acom.com>,
	naveen yadav <yad.naveen@...il.com>, linux-mips@...ux-mips.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: kmemleak for MIPS

On Tue, 2011-03-29 at 12:38 +0100, Maxin John wrote:
> Hi,
> 
> > You may want to disable the kmemleak testing to reduce the amount of
> > leaks reported.
> 
> The kmemleak results in MIPS that I have included in the previous mail
> were obtained during the booting of the malta kernel.
> Later, I have checked the "real" usage by using the default
> "kmemleak_test" module.
> 
> Following output shows the kmemleak results when I used the "kmemleak_test.ko"

Yes, that's fine to test kmemleak and show that it reports issues on
MIPS. But it shouldn't report other leaks if the test module isn't
loaded at all (removing it wouldn't remove the leaks reported as they
are permanent).

> debian-mips:~# cat /sys/kernel/debug/kmemleak
> ........

These were caused by the kmemleak test.
> 
> > These are probably false positives.
> The previous results could be false positives. However, the current
> results are not false positives as we have intentionally created the
> memory leaks using the test module.

I was only referring to those leaks coming from udp.c and ignored the
kmemleak tests (that's why I said that you should run it again without
the kmemleak_test.ko).

> > Since the pointer referring this
> > block (udp_table) is __read_mostly, is it possible that the
> > corresponding section gets placed outside the _sdata.._edata range?
> 
> I am not sure about this. Please  let know how can I check this.

Boot the kernel with kmemleak enabled but don't load kmemleak_test.ko.
Than you can either wait 10-15 minutes or force a scan with:

echo scan > /sys/kernel/debug/kmemleak
echo scan > /sys/kernel/debug/kmemleak
cat /sys/kernel/debug/kmemleak.

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