linux-kernel - Re: [2.6.32-rc3 kmemleak] WARNING:atkernel/lockdep.c:3161check

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:	Wed, 14 Oct 2009 15:55:13 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:	paulmck@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org
Subject: Re: [2.6.32-rc3 kmemleak]
	WARNING:atkernel/lockdep.c:3161check_flags+0xbe/0x180()

On Wed, 2009-10-14 at 22:12 +0900, Tetsuo Handa wrote:
> Catalin Marinas wrote:
> > Until I manage to reproduce the problem, could you please try the patch
> > below:
> > 
> > diff --git a/mm/slab.c b/mm/slab.c
> > index 7dfa481..f8f671b 100644
> > --- a/mm/slab.c
> > +++ b/mm/slab.c
> > @@ -2263,7 +2263,8 @@ kmem_cache_create (const char *name, size_t size, size_t align,
> >  	 * (bootstrapping cannot cope with offslab caches so don't do
> >  	 * it too early on.)
> >  	 */
> > -	if ((size >= (PAGE_SIZE >> 3)) && !slab_early_init)
> > +	if ((size >= (PAGE_SIZE >> 3)) && !slab_early_init &&
> > +	    !(cachep->flags & SLAB_NOLEAKTRACE))
> >  		/*
> >  		 * Size is large, assume best to place the slab management obj
> >  		 * off-slab (should allow better packing of objs).
> 
> It is "&& !(flags & SLAB_NOLEAKTRACE)" rather than
> "&& !(cachep->flags & SLAB_NOLEAKTRACE)" because "cachep->flags = flags;" is
> not yet done, isn't it?

Yes, thanks.

> After adding "&& !(flags & SLAB_NOLEAKTRACE)", I got out of memory error later.

Could you check the object_cache->obj_size/buffer_size and
scan_area_cache->obj_size/buffer_size in mm/kmemleak.c? The first
impression is that these somehow are too big when they shouldn't.

>>From your .config, you have DEBUG_PAGEALLOC enabled which may set
buffer_size to a full PAGE_SIZE. This size also enables the off slab
mgmt data.

If that's the case, my patch is still correct to avoid the recursive
call but OOM is quite plausible (every object allocated needs another
page for the kmemleak metadata).

> > I don't think we should add SLAB_NOLEAKTRACE to slabmgmt since in theory
> > it should work. Is there a slabmgmt allocated for each
> > kmem_cache_alloc()? If yes, it will indeed get into infinite recursive
> > calls. If not, kmemleak should be able to cope though in some situations
> > it may still overflow.
> 
> Will you tell me how to check it? (Some /proc file?)

Looking at the code, it seems that with off slab mgmt data, it allocates
one slabmgmt object per kmem_cache_alloc() call. The slabp_cache is set
to one of the general cachep which are also used by kmalloc, so we can't
really set SLAB_NOLEAKTRACE on them.

Regards.

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