Messages in this thread | | | Subject | Re: [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161check_flags+0xbe/0x180() | From | Catalin Marinas <> | Date | Tue, 13 Oct 2009 13:00:01 +0100 |
| |
On Tue, 2009-10-13 at 12:17 +0900, Tetsuo Handa wrote: > Catalin Marinas wrote: > > On Thu, 2009-10-08 at 21:34 +0900, Tetsuo Handa wrote: > > > If the stack dump is correct, this error indicates circular function calls. > > > We need to find the location which triggers circular memory allocation. > > > Maybe just checking for NULL is not sufficient. > > > > The circular function call is expected, nothing to do with the NULL > > checking. You get callbacks from the slab allocator into kmemleak which > > also allocates memory (but this latter call isn't traced - similar > > behaviour in kmemtrace). > > So, something is preventing kmemleak from being traced, isn't it?
The SLAB_NOLEAKTRACE flag is preventing kmemleak from tracing itself since it needs to do some memory allocations for its internal data.
When kmemleak calls the slab allocator, it uses the GFP_KERNEL| GFP_ATOMIC flags passed by the original alloc caller to the slab allocator. Is there any other flag that would need to be preserved? If the alloc caller doesn't use GFP_ATOMIC when it should, neither does kmemleak so you would also get a warning in kmemleak.
But in this particular case, you say that disabling kmemleak no longer shows this warning.
> I tried 2.6.32-rc4 , but the error is not yet fixed. How can I help you? > > [ 0.000000] Linux version 2.6.32-rc4 (root@tomoyo) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #2 SMP Tue Oct 13 11:10:53 JST 2009 > (...snipped...) > [ 0.000000] ------------------------------------------------------- > [ 0.000000] Good, all 218 testcases passed! | > [ 0.000000] --------------------------------- > [ 0.000000] ------------[ cut here ]------------ > [ 0.000000] WARNING: at kernel/lockdep.c:3161 check_flags+0xbe/0x180() > [ 0.000000] Hardware name: VMware Virtual Platform > [ 0.000000] Modules linked in: > [ 0.000000] Pid: 0, comm: swapper Not tainted 2.6.32-rc4 #2 > [ 0.000000] Call Trace: > [ 0.000000] [<c10417dd>] ? printk+0x1d/0x30 > [ 0.000000] [<c10703ae>] ? check_flags+0xbe/0x180 > [ 0.000000] [<c1040d91>] warn_slowpath_common+0x81/0xa0 > [ 0.000000] [<c10703ae>] ? check_flags+0xbe/0x180 > [ 0.000000] [<c1040e0a>] warn_slowpath_null+0x1a/0x30 > [ 0.000000] [<c10703ae>] check_flags+0xbe/0x180 > [ 0.000000] [<c106e23e>] lockdep_trace_alloc+0x2e/0x60 > [ 0.000000] [<c10cfded>] kmem_cache_alloc+0x2d/0x1d0 > [ 0.000000] [<c106e00b>] ? trace_hardirqs_off+0xb/0x10 > [ 0.000000] [<c10ceeaf>] ? alloc_slabmgmt+0x5f/0x80 > [ 0.000000] [<c10ceeaf>] alloc_slabmgmt+0x5f/0x80 > [ 0.000000] [<c10cf2ee>] cache_grow+0xae/0x170 > [ 0.000000] [<c10cf90b>] cache_alloc_refill+0x17b/0x210 > [ 0.000000] [<c10cff6a>] kmem_cache_alloc+0x1aa/0x1d0 > [ 0.000000] [<c10cd8c8>] ? obj_size+0x8/0x10 > [ 0.000000] [<c10d3879>] ? create_object+0x29/0x220 > [ 0.000000] [<c10d3879>] create_object+0x29/0x220 > [ 0.000000] [<c10cd8b8>] ? obj_offset+0x8/0x10 > [ 0.000000] [<c10cdf8a>] ? poison_obj+0x2a/0x50 > [ 0.000000] [<c1321613>] kmemleak_alloc+0x83/0xd0 > [ 0.000000] [<c10ceeaf>] ? alloc_slabmgmt+0x5f/0x80 > [ 0.000000] [<c10cff45>] kmem_cache_alloc+0x185/0x1d0 > [ 0.000000] [<c10ceeaf>] ? alloc_slabmgmt+0x5f/0x80 > [ 0.000000] [<c10ceeaf>] alloc_slabmgmt+0x5f/0x80 > [ 0.000000] [<c10cf2ee>] cache_grow+0xae/0x170 > [ 0.000000] [<c10cf90b>] cache_alloc_refill+0x17b/0x210 > [ 0.000000] [<c10cff6a>] kmem_cache_alloc+0x1aa/0x1d0 > [ 0.000000] [<c10cd8c8>] ? obj_size+0x8/0x10 > [ 0.000000] [<c10d3879>] ? create_object+0x29/0x220 > [ 0.000000] [<c10d3879>] create_object+0x29/0x220
This is the "DEBUG_LOCKS_WARN_ON(current->softirqs_enabled)" warning. I'm not sure why this happens but from the trace it seems that kmemleak is being called recursively via alloc_slabmgmt() which is caused by kmem_cache_alloc() called from create_object() in kmemleak.c.
Could you send me your .config file and I'll try to reproduce this as well?
Thanks.
-- Catalin
| |