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

[Tetsuo Handa]

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);

although it unlikely fails.



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

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

# cat /sys/kernel/debug/kmemleak
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
unreferenced object 0xf703d9a0 (size 24):
  comm "swapper", pid 0, jiffies 4294892296
  hex dump (first 24 bytes):
    c0 8d d4 f6 c0 87 d4 f6 03 00 00 00 d4 fc 40 d2  ..............@.
    24 88 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
unreferenced object 0xf703d970 (size 24):
  comm "swapper", pid 0, jiffies 4294892296
  hex dump (first 24 bytes):
    00 00 00 00 60 c5 cc c1 02 00 00 00 1c 7e cd f5  ....`........~..
    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
unreferenced object 0xf703d8e0 (size 24):
  comm "swapper", pid 0, jiffies 4294892296
  hex dump (first 24 bytes):
    00 00 00 00 20 ee cf c1 02 00 00 00 64 a9 89 d7  .... .......d...
    24 88 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
unreferenced object 0xf6d48dc0 (size 24):
  comm "getty", pid 2567, jiffies 4294904897
  hex dump (first 24 bytes):
    00 00 00 00 a0 d9 03 f7 03 00 00 00 90 fc 40 d2  ..............@.
    24 88 4c c1 00 00 00 00                          $.L.....
  backtrace:
    [<c10d3944>] create_object+0xe4/0x220
    [<c13226b3>] kmemleak_alloc+0x83/0xd0
    [<c10cff55>] kmem_cache_alloc+0x185/0x1d0
    [<c11b80ec>] fill_pool+0x3c/0xa0
    [<c11b856c>] __debug_object_init+0x1c/0xf0
    [<c11b867a>] debug_object_init_on_stack+0x1a/0x20
    [<c105e0a6>] hrtimer_init_on_stack+0x26/0x40
    [<c105ec0f>] hrtimer_nanosleep+0x3f/0x100
    [<c105ed27>] sys_nanosleep+0x57/0x60
    [<c1002f59>] syscall_call+0x7/0xb
    [<ffffffff>] 0xffffffff
unreferenced object 0xf6d487c0 (size 24):
  comm "getty", pid 2563, jiffies 4294904897
  hex dump (first 24 bytes):
    a0 d9 03 f7 88 67 c6 c1 03 00 00 00 50 fb 40 d2  .....g......P.@.
    24 88 4c c1 00 00 00 00                          $.L.....
  backtrace:
    [<c10d3944>] create_object+0xe4/0x220
    [<c13226b3>] kmemleak_alloc+0x83/0xd0
    [<c10cff55>] kmem_cache_alloc+0x185/0x1d0
    [<c11b80ec>] fill_pool+0x3c/0xa0
    [<c11b856c>] __debug_object_init+0x1c/0xf0
    [<c11b867a>] debug_object_init_on_stack+0x1a/0x20
    [<c105e0a6>] hrtimer_init_on_stack+0x26/0x40
    [<c105ec0f>] hrtimer_nanosleep+0x3f/0x100
    [<c105ed27>] sys_nanosleep+0x57/0x60
    [<c1002f59>] syscall_call+0x7/0xb
    [<ffffffff>] 0xffffffff

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?

Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/