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.030 / U:0.360 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site