lkml.org 
[lkml]   [2009]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161 check_flags+0xbe/0x180()
From
Date
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.


\
 
 \ /
  Last update: 2009-10-15 05:55    [W:0.090 / U:0.092 seconds]
©2003-2014 Jasper Spaans. Advertise on this site