Re: [2.6.32-rc3 kmemleak] WARNING:atkernel/lockdep.c:3161check_flags+0xbe/0x180()

[Catalin Marinas <catalin.marinas@arm.com>]

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