linux-kernel - Re: linux-next: Tree for March 30: [BUG] kmemleak page fault

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: <1238578208.14550.4.camel@pc1117.cambridge.arm.com>
Date:	Wed, 01 Apr 2009 10:30:08 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Matthias Kaehlcke <matthias@...hlcke.net>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: Tree for March 30: [BUG] kmemleak page fault

On Mon, 2009-03-30 at 14:24 +0200, Matthias Kaehlcke wrote:
> linux-next 20090330 causes the following page fault on an edb9302
> (ARM) like board:
> 
> # Unable to handle kernel paging request at virtual address 00535447
> pgd = c56b0000
> [00535447] *pgd=00000000
> Internal error: Oops: 3 [#1] PREEMPT
> Modules linked in:
> CPU: 0    Not tainted  (2.6.29-next-20090330 #6)
> PC is at kmemleak_scan+0x158/0x3ac
> LR is at find_and_get_object+0xe0/0x104
> pc : [<c00aa5cc>]    lr : [<c00a99d8>]    psr: 00000013
> sp : c55bff78  ip : c55bff28  fp : c55bffa4
> r10: c0322718  r9 : c035fa6c  r8 : c035f048
> r7 : c035f044  r6 : 00005800  r5 : 00004981  r4 : 00093020
> r3 : 00535443  r2 : 414f4c5f  r1 : 00000001  r0 : c0400020
> Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> Control: 0000717f  Table: 0567c000  DAC: 00000017
> Process kmemleak (pid: 343, stack limit = 0xc55be268)
[...]
> the fault is reproducible and happens some seconds after having
> finished the boot process. please tell me if you need more information
> (like the .config, ...) in order to track this down

Yes, the .config would be useful. I'm mainly interested in which slab
allocator you are using. I'm testing kmemleak mainly on ARM and haven't
seen any issues.

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/