Messages in this thread | | | Subject | Re: [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161 check_flags+0xbe/0x180() | From | Tetsuo Handa <> | Date | Thu, 15 Oct 2009 12:52:07 +0900 |
| |
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.
| |