linux-kernel - Re: kmemleak: Protect the seq start/next/stop sequence byrcu_read

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: <1250174680.14019.24.camel@pc1117.cambridge.arm.com>
Date:	Thu, 13 Aug 2009 15:44:40 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: kmemleak: Protect the seq start/next/stop sequence
	byrcu_read_lock()

On Thu, 2009-08-13 at 11:44 +0200, Ingo Molnar wrote:
> i still have the full crashlog (attached below) - you can see all 
> the mappings (and other details) in that.
> 
> It's a fairly regular whitebox PC with 1GB of RAM:
> 
> [    0.000000] initial memory mapped : 0 - 20000000
> [    0.000000] init_memory_mapping: 0000000000000000-000000003fff0000
> [    0.000000]  0000000000 - 003fe00000 page 2M
> [    0.000000]  003fe00000 - 003fff0000 page 4k
> [    0.000000] kernel direct mapping tables up to 3fff0000 @ 10000-13000

So the kmemleak fault address 0020000000 should be valid. Is this true
for all contexts? A later message in the log shows this:

> [    0.000000] Mapping aperture over 65536 KB of RAM @ 20000000

This comes from allocate_aperture() in arch/x86/kernel/aperture_64.c.
Does it mean that the kernel direct mapping at 0x20000000 may be
unmapped? Or is it initially mapped and unmapped later, possibly when
kmemleak is scanning the memory?

Since now kmemleak tracks alloc_bootmem() blocks, it will scan the
aperture above as well. An annotation would tell kmemleak to ignore it:

diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
index 676debf..cb690b3 100644
--- a/arch/x86/kernel/aperture_64.c
+++ b/arch/x86/kernel/aperture_64.c
@@ -94,6 +94,11 @@ static u32 __init allocate_aperture(void)
 	 * code for safe
 	 */
 	p = __alloc_bootmem_nopanic(aper_size, aper_size, 512ULL<<20);
+	/*
+	 * Kmemleak should not scan this block as it may not be mapped via the
+	 * kernel direct mapping.
+	 */
+	kmemleak_ignore(p);
 	if (!p || __pa(p)+aper_size > 0xffffffff) {
 		printk(KERN_ERR
 			"Cannot allocate aperture memory hole (%p,%uK)\n",

We could as well use kmemleak_no_scan(p) instead of kmemleak_ignore().

Could you please let me know if the patch solves the page fault?

Thanks.

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