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

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

On Thu, 2009-10-15 at 12:52 +0900, Tetsuo Handa wrote:
> Catalin Marinas wrote:
> > 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.
> 
> Yes. object_cache->buffer_size was set to PAGE_SIZE.
> 
> [    0.000000] ***** object_cache->obj_size = 200 *****
> [    0.000000] ***** object_cache->buffer_size = 4096 *****
> [    0.000000] ***** scan_area_cache->obj_size = 16 *****
> [    0.000000] ***** scan_area_cache->buffer_size = 40 *****
> 
> I thought we should also pass SLAB_PANIC flag to
> 
> 	object_cache = KMEM_CACHE(kmemleak_object, SLAB_NOLEAKTRACE);
> 	scan_area_cache = KMEM_CACHE(kmemleak_scan_area, SLAB_NOLEAKTRACE);

I think it would be better to disable kmemleak than panicking.

> Don't we need to disable kmemleak routine (call kmemleak_disable()?)
> when early_alloc() failed in order to avoid false positives?

This is already done in create_object() via kmemleak_stop().

> I got below entries.
> (Similar entries are posted at http://lkml.org/lkml/2009/10/14/571 )

As a general rule with kmemleak, it would be useful to run a few "echo
scan > /sys/kernel/debug/kmemleak" to make sure they are not just
transient false positives.

> unreferenced object 0xf703d460 (size 24):
>   comm "swapper", pid 0, jiffies 4294892296
>   hex dump (first 24 bytes):
>     00 00 00 00 e8 97 c7 c1 02 00 00 00 1c 1e 21 d5  ..............!.
>     0c 93 4c c1 00 00 00 00                          ..L.....
>   backtrace:
>     [<c10d3944>] create_object+0xe4/0x220
>     [<c13226b3>] kmemleak_alloc+0x83/0xd0
>     [<c10cff55>] kmem_cache_alloc+0x185/0x1d0
>     [<c11b8d7d>] debug_objects_replace_static_objects+0x2d/0x1a0
>     [<c1518e34>] debug_objects_mem_init+0x64/0x70
>     [<c14f9974>] start_kernel+0x194/0x290
>     [<c14f9095>] i386_start_kernel+0x65/0xa0
>     [<ffffffff>] 0xffffffff

I get these reports as well and I think they are false positives. I
looked at the code in question and couldn't figure out why kmemleak is
confused.

> However, after doing
> 
>   # echo scan > /sys/kernel/debug/kmemleak
> 
> /sys/kernel/debug/kmemleak became empty.
> Does this mean that above entries were not memory leak?

Yes, they are just some transient memory leaks. This is usually caused
by the fact that kmemleak doesn't stop the allocations when scanning
(many garbage collectors do this). There are very few cases of false
positives left and debug_objects is one of them

Thanks.

-- 
Catalin