linux-kernel - Re: [REGRESSION 2.6.35+] crash (maybe kmemleak related)

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: <1281695919.25390.31.camel@e102109-lin.cambridge.arm.com>
Date:	Fri, 13 Aug 2010 11:38:39 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Pekka Enberg <penberg@...nel.org>
Cc:	Maxim Levitsky <maximlevitsky@...il.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Pekka Enberg <penberg@...helsinki.fi>
Subject: Re: [REGRESSION 2.6.35+] crash (maybe kmemleak related)

On Fri, 2010-08-13 at 11:28 +0100, Pekka Enberg wrote:
> On Fri, Aug 13, 2010 at 12:26 PM, Catalin Marinas
> <catalin.marinas@....com> wrote:
> > This kmemleak warning tells us that the kmemleak_alloc() hook got called
> > with a pointer (0xffff880079fe6000) that's already registered with
> > kmemleak. The first trace tells us where the hook gets called from while
> > the second trace shows the details of the already existing pointer.
> >
> > So __getname() allocates the same 4096 bytes block twice via
> > kmem_cache_alloc() but there is no kmemleak_free() call between them and
> > kmemleak gives up. It disables itself but does not panic the system.
> >
> > Pekka, were there any recent changes in the slab/slob/slub area and
> > maybe a kmemleak_free() hook is missing? Or maybe something else went
> > wrong with the slab allocator and returns an already allocated block?
> >
> >> <0>[   24.578578] general protection fault: 0000 [#1] PREEMPT SMP
> >
> > That's what's causing the fault but it doesn't seem to be related to
> > kmemleak.
> 
> Looking at Maxim's log, slab seems to be corrupted. I don't see
> anything obviously wrong with SLUB (which he is using) kmemleak hooks
> so it doesn't look like a slab allocator problem either. Could this be
> related to the bootmem kmemleak hook changes?

I don't think in this case since both allocations came via
kmem_cache_alloc() (and not one from bootmem and the other from slab, as
it happened to me in the past). But it's worth trying with kmemleak
disabled.

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