* [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161 check_flags+0xbe/0x180()
@ 2009-10-05 3:15 Tetsuo Handa
2009-10-05 8:55 ` Catalin Marinas
2009-10-07 15:51 ` Paul E. McKenney
0 siblings, 2 replies; 17+ messages in thread
From: Tetsuo Handa @ 2009-10-05 3:15 UTC (permalink / raw)
To: catalin.marinas; +Cc: linux-kernel
Hello.
I got this error.
[ 0.000000] Linux version 2.6.32-rc3 (root@tomoyo) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #1 SMP Mon Oct 5 11:24:05 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-rc3 #1
[ 0.000000] Call Trace:
[ 0.000000] [<c104182d>] ? printk+0x1d/0x30
[ 0.000000] [<c107069e>] ? check_flags+0xbe/0x180
[ 0.000000] [<c1040de1>] warn_slowpath_common+0x81/0xa0
[ 0.000000] [<c107069e>] ? check_flags+0xbe/0x180
[ 0.000000] [<c1040e5a>] warn_slowpath_null+0x1a/0x30
[ 0.000000] [<c107069e>] check_flags+0xbe/0x180
[ 0.000000] [<c106e52e>] lockdep_trace_alloc+0x2e/0x60
[ 0.000000] [<c10cfedd>] kmem_cache_alloc+0x2d/0x1d0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c106e22b>] ? trace_hardirqs_on+0xb/0x10
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
[ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
[ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
[ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
[ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
[ 0.000000] [<c10d3969>] create_object+0x29/0x220
[ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
[ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
[ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
[ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
[ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
[ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
[ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
[ 0.000000] [<c10d3969>] create_object+0x29/0x220
[ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
[ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
[ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
[ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
[ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
[ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
[ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
[ 0.000000] [<c10d3969>] create_object+0x29/0x220
[ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
[ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
[ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
[ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
[ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
[ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
[ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
[ 0.000000] [<c10d3969>] create_object+0x29/0x220
[ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
[ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
[ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
[ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
[ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
[ 0.000000] [<c10cf9c4>] ? cache_alloc_refill+0x144/0x210
[ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
[ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
[ 0.000000] [<c10d3969>] create_object+0x29/0x220
[ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
[ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
[ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
[ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
[ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
[ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
[ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
[ 0.000000] [<c10d3969>] create_object+0x29/0x220
[ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
[ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
[ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
[ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
[ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
[ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
[ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
[ 0.000000] [<c10d3969>] create_object+0x29/0x220
[ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
[ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
[ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
[ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
[ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
[ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
[ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
[ 0.000000] [<c10d3969>] create_object+0x29/0x220
[ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
[ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
[ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
[ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
[ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
[ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
[ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
[ 0.000000] [<c10d3969>] create_object+0x29/0x220
[ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
[ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
[ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
[ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
[ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
[ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
[ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
[ 0.000000] [<c10d3969>] create_object+0x29/0x220
[ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
[ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
[ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
[ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
[ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
[ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
[ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
[ 0.000000] [<c10d3969>] create_object+0x29/0x220
[ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
[ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
[ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
[ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
[ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
[ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
[ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
[ 0.000000] [<c10d3969>] create_object+0x29/0x220
[ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
[ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
[ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
[ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
[ 0.000000] <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ>(...snipped...)
Adding kmemleak=off to kernel command line solves this error.
Config is at http://I-love.SAKURA.ne.jp/tmp/config-2.6.32-rc3
By the way,
> static void early_alloc(struct early_log *log)
> {
> struct kmemleak_object *object;
> unsigned long flags;
> int i;
>
> if (!atomic_read(&kmemleak_enabled) || !log->ptr || IS_ERR(log->ptr))
> return;
>
> /*
> * RCU locking needed to ensure object is not freed via put_object().
> */
> rcu_read_lock();
> object = create_object((unsigned long)log->ptr, log->size,
> log->min_count, GFP_KERNEL);
I think we can't use GFP_KERNEL inside rcu_read_lock()...
> spin_lock_irqsave(&object->lock, flags);
> for (i = 0; i < log->trace_len; i++)
> object->trace[i] = log->trace[i];
> object->trace_len = log->trace_len;
> spin_unlock_irqrestore(&object->lock, flags);
> rcu_read_unlock();
> }
[PATCH 2.6.32-rc3] kmemleak: Use GFP_ATOMIC for early_alloc().
We can't use GFP_KERNEL inside rcu_read_lock().
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
mm/kmemleak.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.32-rc3.orig/mm/kmemleak.c
+++ linux-2.6.32-rc3/mm/kmemleak.c
@@ -833,7 +833,7 @@ static void early_alloc(struct early_log
*/
rcu_read_lock();
object = create_object((unsigned long)log->ptr, log->size,
- log->min_count, GFP_KERNEL);
+ log->min_count, GFP_ATOMIC);
spin_lock_irqsave(&object->lock, flags);
for (i = 0; i < log->trace_len; i++)
object->trace[i] = log->trace[i];
Regards.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161 check_flags+0xbe/0x180()
2009-10-05 3:15 [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161 check_flags+0xbe/0x180() Tetsuo Handa
@ 2009-10-05 8:55 ` Catalin Marinas
2009-10-07 15:51 ` Paul E. McKenney
1 sibling, 0 replies; 17+ messages in thread
From: Catalin Marinas @ 2009-10-05 8:55 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: linux-kernel
On Mon, 2009-10-05 at 12:15 +0900, Tetsuo Handa wrote:
> [PATCH 2.6.32-rc3] kmemleak: Use GFP_ATOMIC for early_alloc().
>
> We can't use GFP_KERNEL inside rcu_read_lock().
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
> mm/kmemleak.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-2.6.32-rc3.orig/mm/kmemleak.c
> +++ linux-2.6.32-rc3/mm/kmemleak.c
> @@ -833,7 +833,7 @@ static void early_alloc(struct early_log
> */
> rcu_read_lock();
> object = create_object((unsigned long)log->ptr, log->size,
> - log->min_count, GFP_KERNEL);
> + log->min_count, GFP_ATOMIC);
> spin_lock_irqsave(&object->lock, flags);
> for (i = 0; i < log->trace_len; i++)
> object->trace[i] = log->trace[i];
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Thanks.
--
Catalin
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161 check_flags+0xbe/0x180()
2009-10-05 3:15 [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161 check_flags+0xbe/0x180() Tetsuo Handa
2009-10-05 8:55 ` Catalin Marinas
@ 2009-10-07 15:51 ` Paul E. McKenney
2009-10-08 12:34 ` [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161check_flags+0xbe/0x180() Tetsuo Handa
2009-10-08 12:39 ` Catalin Marinas
1 sibling, 2 replies; 17+ messages in thread
From: Paul E. McKenney @ 2009-10-07 15:51 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: catalin.marinas, linux-kernel
On Mon, Oct 05, 2009 at 12:15:12PM +0900, Tetsuo Handa wrote:
> Hello.
>
> I got this error.
>
> [ 0.000000] Linux version 2.6.32-rc3 (root@tomoyo) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #1 SMP Mon Oct 5 11:24:05 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-rc3 #1
> [ 0.000000] Call Trace:
> [ 0.000000] [<c104182d>] ? printk+0x1d/0x30
> [ 0.000000] [<c107069e>] ? check_flags+0xbe/0x180
> [ 0.000000] [<c1040de1>] warn_slowpath_common+0x81/0xa0
> [ 0.000000] [<c107069e>] ? check_flags+0xbe/0x180
> [ 0.000000] [<c1040e5a>] warn_slowpath_null+0x1a/0x30
> [ 0.000000] [<c107069e>] check_flags+0xbe/0x180
> [ 0.000000] [<c106e52e>] lockdep_trace_alloc+0x2e/0x60
> [ 0.000000] [<c10cfedd>] kmem_cache_alloc+0x2d/0x1d0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c106e22b>] ? trace_hardirqs_on+0xb/0x10
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
> [ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
> [ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
> [ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
> [ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
> [ 0.000000] [<c10d3969>] create_object+0x29/0x220
> [ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
> [ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
> [ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
> [ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
> [ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
> [ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
> [ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
> [ 0.000000] [<c10d3969>] create_object+0x29/0x220
> [ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
> [ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
> [ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
> [ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
> [ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
> [ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
> [ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
> [ 0.000000] [<c10d3969>] create_object+0x29/0x220
> [ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
> [ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
> [ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
> [ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
> [ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
> [ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
> [ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
> [ 0.000000] [<c10d3969>] create_object+0x29/0x220
> [ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
> [ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
> [ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
> [ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
> [ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
> [ 0.000000] [<c10cf9c4>] ? cache_alloc_refill+0x144/0x210
> [ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
> [ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
> [ 0.000000] [<c10d3969>] create_object+0x29/0x220
> [ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
> [ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
> [ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
> [ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
> [ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
> [ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
> [ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
> [ 0.000000] [<c10d3969>] create_object+0x29/0x220
> [ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
> [ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
> [ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
> [ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
> [ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
> [ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
> [ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
> [ 0.000000] [<c10d3969>] create_object+0x29/0x220
> [ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
> [ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
> [ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
> [ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
> [ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
> [ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
> [ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
> [ 0.000000] [<c10d3969>] create_object+0x29/0x220
> [ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
> [ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
> [ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
> [ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
> [ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
> [ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
> [ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
> [ 0.000000] [<c10d3969>] create_object+0x29/0x220
> [ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
> [ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
> [ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
> [ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
> [ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
> [ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
> [ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
> [ 0.000000] [<c10d3969>] create_object+0x29/0x220
> [ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
> [ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
> [ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
> [ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
> [ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
> [ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
> [ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
> [ 0.000000] [<c10d3969>] create_object+0x29/0x220
> [ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
> [ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
> [ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cef9f>] alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10cf3de>] cache_grow+0xae/0x170
> [ 0.000000] [<c10cf9fb>] cache_alloc_refill+0x17b/0x210
> [ 0.000000] [<c10d005a>] kmem_cache_alloc+0x1aa/0x1d0
> [ 0.000000] [<c10cd9b8>] ? obj_size+0x8/0x10
> [ 0.000000] [<c10d3969>] ? create_object+0x29/0x220
> [ 0.000000] [<c10d3969>] create_object+0x29/0x220
> [ 0.000000] [<c10cd9a8>] ? obj_offset+0x8/0x10
> [ 0.000000] [<c10ce07a>] ? poison_obj+0x2a/0x50
> [ 0.000000] [<c1321693>] kmemleak_alloc+0x83/0xd0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] [<c10d0035>] kmem_cache_alloc+0x185/0x1d0
> [ 0.000000] [<c106e1b7>] ? trace_hardirqs_on_caller+0xf7/0x160
> [ 0.000000] [<c10cef9f>] ? alloc_slabmgmt+0x5f/0x80
> [ 0.000000] <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ>(...snipped...)
>
> Adding kmemleak=off to kernel command line solves this error.
> Config is at http://I-love.SAKURA.ne.jp/tmp/config-2.6.32-rc3
>
> By the way,
> > static void early_alloc(struct early_log *log)
> > {
> > struct kmemleak_object *object;
> > unsigned long flags;
> > int i;
> >
> > if (!atomic_read(&kmemleak_enabled) || !log->ptr || IS_ERR(log->ptr))
> > return;
> >
> > /*
> > * RCU locking needed to ensure object is not freed via put_object().
> > */
> > rcu_read_lock();
> > object = create_object((unsigned long)log->ptr, log->size,
> > log->min_count, GFP_KERNEL);
> I think we can't use GFP_KERNEL inside rcu_read_lock()...
> > spin_lock_irqsave(&object->lock, flags);
> > for (i = 0; i < log->trace_len; i++)
> > object->trace[i] = log->trace[i];
> > object->trace_len = log->trace_len;
> > spin_unlock_irqrestore(&object->lock, flags);
> > rcu_read_unlock();
> > }
>
> [PATCH 2.6.32-rc3] kmemleak: Use GFP_ATOMIC for early_alloc().
>
> We can't use GFP_KERNEL inside rcu_read_lock().
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
> mm/kmemleak.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-2.6.32-rc3.orig/mm/kmemleak.c
> +++ linux-2.6.32-rc3/mm/kmemleak.c
> @@ -833,7 +833,7 @@ static void early_alloc(struct early_log
> */
> rcu_read_lock();
> object = create_object((unsigned long)log->ptr, log->size,
> - log->min_count, GFP_KERNEL);
> + log->min_count, GFP_ATOMIC);
Won't we need to check for object==NULL?
Thanx, Paul
> spin_lock_irqsave(&object->lock, flags);
> for (i = 0; i < log->trace_len; i++)
> object->trace[i] = log->trace[i];
>
> Regards.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161check_flags+0xbe/0x180()
2009-10-07 15:51 ` Paul E. McKenney
@ 2009-10-08 12:34 ` Tetsuo Handa
2009-10-08 12:42 ` Catalin Marinas
2009-10-08 12:39 ` Catalin Marinas
1 sibling, 1 reply; 17+ messages in thread
From: Tetsuo Handa @ 2009-10-08 12:34 UTC (permalink / raw)
To: paulmck, catalin.marinas; +Cc: linux-kernel
Hello.
Paul E. McKenney wrote:
> > --- linux-2.6.32-rc3.orig/mm/kmemleak.c
> > +++ linux-2.6.32-rc3/mm/kmemleak.c
> > @@ -833,7 +833,7 @@ static void early_alloc(struct early_log
> > */
> > rcu_read_lock();
> > object = create_object((unsigned long)log->ptr, log->size,
> > - log->min_count, GFP_KERNEL);
> > + log->min_count, GFP_ATOMIC);
>
> Won't we need to check for object==NULL?
>
> Thanx, Paul
>
> > spin_lock_irqsave(&object->lock, flags);
> > for (i = 0; i < log->trace_len; i++)
> > object->trace[i] = log->trace[i];
> >
Indeed. We need to check for NULL.
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161 check_flags+0xbe/0x180()
2009-10-07 15:51 ` Paul E. McKenney
2009-10-08 12:34 ` [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161check_flags+0xbe/0x180() Tetsuo Handa
@ 2009-10-08 12:39 ` Catalin Marinas
1 sibling, 0 replies; 17+ messages in thread
From: Catalin Marinas @ 2009-10-08 12:39 UTC (permalink / raw)
To: paulmck; +Cc: Tetsuo Handa, linux-kernel
On Wed, 2009-10-07 at 08:51 -0700, Paul E. McKenney wrote:
> On Mon, Oct 05, 2009 at 12:15:12PM +0900, Tetsuo Handa wrote:
> > --- linux-2.6.32-rc3.orig/mm/kmemleak.c
> > +++ linux-2.6.32-rc3/mm/kmemleak.c
> > @@ -833,7 +833,7 @@ static void early_alloc(struct early_log
> > */
> > rcu_read_lock();
> > object = create_object((unsigned long)log->ptr, log->size,
> > - log->min_count, GFP_KERNEL);
> > + log->min_count, GFP_ATOMIC);
>
> Won't we need to check for object==NULL?
Yes, we need. Thanks.
--
Catalin
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161check_flags+0xbe/0x180()
2009-10-08 12:34 ` [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161check_flags+0xbe/0x180() Tetsuo Handa
@ 2009-10-08 12:42 ` Catalin Marinas
2009-10-13 3:17 ` Tetsuo Handa
0 siblings, 1 reply; 17+ messages in thread
From: Catalin Marinas @ 2009-10-08 12:42 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: paulmck, linux-kernel
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).
--
Catalin
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161check_flags+0xbe/0x180()
2009-10-08 12:42 ` Catalin Marinas
@ 2009-10-13 3:17 ` Tetsuo Handa
2009-10-13 12:00 ` Catalin Marinas
0 siblings, 1 reply; 17+ messages in thread
From: Tetsuo Handa @ 2009-10-13 3:17 UTC (permalink / raw)
To: catalin.marinas; +Cc: paulmck, linux-kernel
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?
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
[ 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
[ 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
[ 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] [<c10cf8d4>] ? cache_alloc_refill+0x144/0x210
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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] <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> <IRQ> (...snipped...)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161check_flags+0xbe/0x180()
2009-10-13 3:17 ` Tetsuo Handa
@ 2009-10-13 12:00 ` Catalin Marinas
2009-10-13 12:57 ` [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161 check_flags+0xbe/0x180() Tetsuo Handa
2009-10-13 15:25 ` [2.6.32-rc3 kmemleak] WARNING: atkernel/lockdep.c:3161check_flags+0xbe/0x180() Tetsuo Handa
0 siblings, 2 replies; 17+ messages in thread
From: Catalin Marinas @ 2009-10-13 12:00 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: paulmck, linux-kernel
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161 check_flags+0xbe/0x180()
2009-10-13 12:00 ` Catalin Marinas
@ 2009-10-13 12:57 ` Tetsuo Handa
2009-10-13 15:25 ` [2.6.32-rc3 kmemleak] WARNING: atkernel/lockdep.c:3161check_flags+0xbe/0x180() Tetsuo Handa
1 sibling, 0 replies; 17+ messages in thread
From: Tetsuo Handa @ 2009-10-13 12:57 UTC (permalink / raw)
To: catalin.marinas; +Cc: paulmck, linux-kernel
Catalin Marinas wrote:
> Could you send me your .config file and I'll try to reproduce this as
> well?
Yes. It is at http://I-love.SAKURA.ne.jp/tmp/config-2.6.32-rc3 .
Above log is obtained using Debian Sarge.
Below log is obtained using CentOS 5.
Adding "kmemleak=off" in CentOS 5 avoids this error.
Full log is at http://I-love.SAKURA.ne.jp/tmp/dmesg-2.6.32-rc4-centos5.txt .
[ 0.000000] Linux version 2.6.32-rc4 (root@tomoyo) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) #2 SMP Tue Oct 13 20:23:13 JST 2009
(...snipped...)
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] WARNING: at kernel/lockdep.c:3161 check_flags+0xf1/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] [<c1064cc1>] ? check_flags+0xf1/0x180
[ 0.000000] BUG: unable to handle kernel paging request at 54205ab1
[ 0.000000] IP: [<c1006e88>] print_context_stack+0x58/0xe0
[ 0.000000] *pde = 00000000
[ 0.000000] Thread overran stack, or stack corrupted
[ 0.000000] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
[ 0.000000] last sysfs file:
[ 0.000000] Modules linked in:
[ 0.000000]
[ 0.000000] Pid: 0, comm: swapper Not tainted (2.6.32-rc4 #2) VMware Virtual Platform
[ 0.000000] EIP: 0060:[<c1006e88>] EFLAGS: 00010016 CPU: 0
[ 0.000000] EIP is at print_context_stack+0x58/0xe0
[ 0.000000] EAX: c1421000 EBX: c1421fb0 ECX: c103c7f5 EDX: 54204649
[ 0.000000] ESI: c1064cc1 EDI: c131d6e0 EBP: c1421f24 ESP: c1421f10
[ 0.000000] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 0.000000] Process swapper (pid: 0, ti=c1421000 task=c146ff60 task.ti=c145d000)
[ 0.000000] Stack:
[ 0.000000] c1421fb8 c1421000 c1421000 c1421fac c1421fb8 c1421f50 c1005e76 c131d6e0
[ 0.000000] <0> c13d29de 00000000 c1421f40 c1421f50 00000000 c13d29de c1421fac 00000000
[ 0.000000] <0> c1421f74 c1006dac c1421fb8 c131d6e0 c13d29de 00000000 c1421fb8 c1421fb8
[ 0.000000] Call Trace:
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] BUG: unable to handle kernel paging request at 54205ab1
[ 0.000000] IP: [<c1006e88>] print_context_stack+0x58/0xe0
[ 0.000000] *pde = 00000000
[ 0.000000] Thread overran stack, or stack corrupted
[ 0.000000] Oops: 0000 [#2] SMP DEBUG_PAGEALLOC
[ 0.000000] last sysfs file:
[ 0.000000] Modules linked in:
[ 0.000000]
[ 0.000000] Pid: 0, comm: swapper Not tainted (2.6.32-rc4 #2) VMware Virtual Platform
[ 0.000000] EIP: 0060:[<c1006e88>] EFLAGS: 00010006 CPU: 0
[ 0.000000] EIP is at print_context_stack+0x58/0xe0
[ 0.000000] EAX: c1421000 EBX: c1421f28 ECX: c103c7f5 EDX: 54204649
[ 0.000000] ESI: c1005e76 EDI: c131d6e0 EBP: c1421d64 ESP: c1421d50
[ 0.000000] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 0.000000] Process swapper (pid: 0, ti=c1421000 task=c146ff60 task.ti=c145d000)
[ 0.000000] Stack:
[ 0.000000] c1421d90 c1421000 c1421000 c1421f10 c1421d90 c1421d90 c1005e76 c131d6e0
[ 0.000000] <0> c13d34df 00000000 c1421d80 c1421d90 00000000 c13d34df c1421f10 c1421ed4
[ 0.000000] <0> c1421db4 c1006dac 00000000 c131d6e0 c13d34df 00000000 c1421f73 00000018
[ 0.000000] Call Trace:
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
(...snipped...)
[ 0.000000] Thread overran stack, or stack corrupted
[ 0.000000] Oops: 0000 [#8] SMP DEBUG_PAGEALLOC
[ 0.000000] last sysfs file:
[ 0.000000] Modules linked in:
[ 0.000000]
[ 0.000000] Pid: 0, comm: swapper Not tainted (2.6.32-rc4 #2) VMware Virtual Platform
[ 0.000000] EIP: 0060:[<c1006e88>] EFLAGS: 00010006 CPU: 0
[ 0.000000] EIP is at print_context_stack+0x58/0xe0
[ 0.000000] EAX: c1421000 EBX: c14214a8 ECX: c103c7f5 EDX: ffffffff
[ 0.000000] ESI: c1005e76 EDI: c131d6e0 EBP: c14212e4 ESP: c14212d0
[ 0.000000] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 0.000000] Process swapper (pid: 0, ti=c1421000 task=c146ff60 task.ti=c145d000)
[ 0.000000] Stack:
[ 0.000000] c1421310 c1421000 c1421000 c1421490 c1421310 c1421310 c1005e76 c131d6e0
[ 0.000000] <0> c13d34df 00000000 c1421300 c1421310 00000000 c13d34df c1421490 c1421454
[ 0.000000] <0> c1421334 c1006dac 00000000 c131d6e0 c13d34df 00000000 c14214f3 00000018
[ 0.000000] Call Trace:
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] [<c1006dac>] ? show_trace_log_lvl+0x4c/0x60
[ 0.000000] [<c1005dc8>] ? show_stack_log_lvl+0xb8/0xe0
[ 0.000000] [<c1005f8a>] ? show_registers+0xca/0x1c0
[ 0.000000] [<c1007121>] ? __die+0xa1/0x100
[ 0.000000] [<c101f5af>] ? no_context+0xff/0x150
[ 0.000000] [<c101f708>] ? __bad_area_nosemaphore+0x58/0x130
[ 0.000000] [<c131abac>] ? _spin_unlock_irqrestore+0x3c/0x60
[ 0.000000] [<c101f887>] ? bad_area_nosemaphore+0x17/0x20
[ 0.000000] [<c101fbaf>] ? do_page_fault+0x17f/0x2a0
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] [<c101fa30>] ? do_page_fault+0x0/0x2a0
[ 0.000000] [<c131b4d3>] ? error_code+0x6b/0x70
[ 0.000000] [<c103c7f5>] ? release_console_sem+0x1c5/0x1f0
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] [<c101fa30>] ? do_page_fault+0x0/0x2a0
[ 0.000000] [<c1006e88>] ? print_context_stack+0x58/0xe0
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] [<c1006dac>] ? show_trace_log_lvl+0x4c/0x60
[ 0.000000] [<c1005dc8>] ? show_stack_log_lvl+0xb8/0xe0
[ 0.000000] [<c1005f8a>] ? show_registers+0xca/0x1c0
[ 0.000000] [<c1007121>] ? __die+0xa1/0x100
[ 0.000000] [<c101f5af>] ? no_context+0xff/0x150
[ 0.000000] [<c101f708>] ? __bad_area_nosemaphore+0x58/0x130
[ 0.000000] [<c131abac>] ? _spin_unlock_irqrestore+0x3c/0x60
[ 0.000000] [<c101f887>] ? bad_area_nosemaphore+0x17/0x20
[ 0.000000] [<c101fbaf>] ? do_page_fault+0x17f/0x2a0
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] [<c101fa30>] ? do_page_fault+0x0/0x2a0
[ 0.000000] [<c131b4d3>] ? error_code+0x6b/0x70
[ 0.000000] [<c103c7f5>] ? release_console_sem+0x1c5/0x1f0
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] [<c101fa30>] ? do_page_fault+0x0/0x2a0
[ 0.000000] [<c1006e88>] ? print_context_stack+0x58/0xe0
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] [<c1006dac>] ? show_trace_log_lvl+0x4c/0x60
[ 0.000000] [<c1005dc8>] ? show_stack_log_lvl+0xb8/0xe0
[ 0.000000] [<c1005f8a>] ? show_registers+0xca/0x1c0
[ 0.000000] [<c1007121>] ? __die+0xa1/0x100
[ 0.000000] [<c101f5af>] ? no_context+0xff/0x150
[ 0.000000] [<c101f708>] ? __bad_area_nosemaphore+0x58/0x130
[ 0.000000] [<c131abac>] ? _spin_unlock_irqrestore+0x3c/0x60
[ 0.000000] [<c101f887>] ? bad_area_nosemaphore+0x17/0x20
[ 0.000000] [<c101fbaf>] ? do_page_fault+0x17f/0x2a0
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] [<c101fa30>] ? do_page_fault+0x0/0x2a0
[ 0.000000] [<c131b4d3>] ? error_code+0x6b/0x70
[ 0.000000] [<c103c7f5>] ? release_console_sem+0x1c5/0x1f0
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] [<c101fa30>] ? do_page_fault+0x0/0x2a0
[ 0.000000] [<c1006e88>] ? print_context_stack+0x58/0xe0
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] [<c1006dac>] ? show_trace_log_lvl+0x4c/0x60
[ 0.000000] [<c1005dc8>] ? show_stack_log_lvl+0xb8/0xe0
[ 0.000000] [<c1005f8a>] ? show_registers+0xca/0x1c0
[ 0.000000] [<c1007121>] ? __die+0xa1/0x100
[ 0.000000] [<c101f5af>] ? no_context+0xff/0x150
[ 0.000000] [<c101f708>] ? __bad_area_nosemaphore+0x58/0x130
[ 0.000000] [<c131abac>] ? _spin_unlock_irqrestore+0x3c/0x60
[ 0.000000] [<c101f887>] ? bad_area_nosemaphore+0x17/0x20
[ 0.000000] [<c101fbaf>] ? do_page_fault+0x17f/0x2a0
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] [<c101fa30>] ? do_page_fault+0x0/0x2a0
[ 0.000000] [<c131b4d3>] ? error_code+0x6b/0x70
[ 0.000000] [<c103c7f5>] ? release_console_sem+0x1c5/0x1f0
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] [<c101fa30>] ? do_page_fault+0x0/0x2a0
[ 0.000000] [<c1006e88>] ? print_context_stack+0x58/0xe0
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] [<c1006dac>] ? show_trace_log_lvl+0x4c/0x60
[ 0.000000] [<c1005dc8>] ? show_stack_log_lvl+0xb8/0xe0
[ 0.000000] [<c1005f8a>] ? show_registers+0xca/0x1c0
[ 0.000000] [<c1007121>] ? __die+0xa1/0x100
[ 0.000000] [<c101f5af>] ? no_context+0xff/0x150
[ 0.000000] [<c101f708>] ? __bad_area_nosemaphore+0x58/0x130
[ 0.000000] [<c131abac>] ? _spin_unlock_irqrestore+0x3c/0x60
[ 0.000000] [<c101f887>] ? bad_area_nosemaphore+0x17/0x20
[ 0.000000] [<c101fbaf>] ? do_page_fault+0x17f/0x2a0
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] [<c101fa30>] ? do_page_fault+0x0/0x2a0
[ 0.000000] [<c131b4d3>] ? error_code+0x6b/0x70
[ 0.000000] [<c103c7f5>] ? release_console_sem+0x1c5/0x1f0
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] [<c101fa30>] ? do_page_fault+0x0/0x2a0
[ 0.000000] [<c1006e88>] ? print_context_stack+0x58/0xe0
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] [<c1006dac>] ? show_trace_log_lvl+0x4c/0x60
[ 0.000000] [<c1005dc8>] ? show_stack_log_lvl+0xb8/0xe0
[ 0.000000] [<c1005f8a>] ? show_registers+0xca/0x1c0
[ 0.000000] [<c1007121>] ? __die+0xa1/0x100
[ 0.000000] [<c101f5af>] ? no_context+0xff/0x150
[ 0.000000] [<c101f708>] ? __bad_area_nosemaphore+0x58/0x130
[ 0.000000] [<c131abac>] ? _spin_unlock_irqrestore+0x3c/0x60
[ 0.000000] [<c101f887>] ? bad_area_nosemaphore+0x17/0x20
[ 0.000000] [<c101fbaf>] ? do_page_fault+0x17f/0x2a0
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] [<c101fa30>] ? do_page_fault+0x0/0x2a0
[ 0.000000] [<c131b4d3>] ? error_code+0x6b/0x70
[ 0.000000] [<c103c7f5>] ? release_console_sem+0x1c5/0x1f0
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] [<c101fa30>] ? do_page_fault+0x0/0x2a0
[ 0.000000] [<c1006e88>] ? print_context_stack+0x58/0xe0
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] [<c1006dac>] ? show_trace_log_lvl+0x4c/0x60
[ 0.000000] [<c1005dc8>] ? show_stack_log_lvl+0xb8/0xe0
[ 0.000000] [<c1005f8a>] ? show_registers+0xca/0x1c0
[ 0.000000] [<c1007121>] ? __die+0xa1/0x100
[ 0.000000] [<c101f5af>] ? no_context+0xff/0x150
[ 0.000000] [<c101f708>] ? __bad_area_nosemaphore+0x58/0x130
[ 0.000000] [<c131abac>] ? _spin_unlock_irqrestore+0x3c/0x60
[ 0.000000] [<c101f887>] ? bad_area_nosemaphore+0x17/0x20
[ 0.000000] [<c101fbaf>] ? do_page_fault+0x17f/0x2a0
[ 0.000000] [<c1064cc1>] ? check_flags+0xf1/0x180
[ 0.000000] [<c101fa30>] ? do_page_fault+0x0/0x2a0
[ 0.000000] [<c131b4d3>] ? error_code+0x6b/0x70
[ 0.000000] [<c103c7f5>] ? release_console_sem+0x1c5/0x1f0
[ 0.000000] [<c1064cc1>] ? check_flags+0xf1/0x180
[ 0.000000] [<c101fa30>] ? do_page_fault+0x0/0x2a0
[ 0.000000] [<c1006e88>] ? print_context_stack+0x58/0xe0
[ 0.000000] [<c1005e76>] ? dump_trace+0x86/0xd0
[ 0.000000] [<c1006dac>] ? show_trace_log_lvl+0x4c/0x60
[ 0.000000] [<c1006ddf>] ? show_trace+0x1f/0x30
[ 0.000000] [<c1006f83>] ? dump_stack+0x73/0x80
[ 0.000000] [<c1064cc1>] ? check_flags+0xf1/0x180
[ 0.000000] [<c103ba41>] ? warn_slowpath_common+0x81/0xa0
[ 0.000000] [<c1064cc1>] ? check_flags+0xf1/0x180
[ 0.000000] [<c103ba7a>] ? warn_slowpath_null+0x1a/0x20
[ 0.000000] [<c1064cc1>] ? check_flags+0xf1/0x180
[ 0.000000] [<c106934c>] ? lock_acquire+0x3c/0xf0
[ 0.000000] <IRQ>
(...snipped...)
Regards.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [2.6.32-rc3 kmemleak] WARNING: atkernel/lockdep.c:3161check_flags+0xbe/0x180()
2009-10-13 12:00 ` Catalin Marinas
2009-10-13 12:57 ` [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161 check_flags+0xbe/0x180() Tetsuo Handa
@ 2009-10-13 15:25 ` Tetsuo Handa
2009-10-14 11:55 ` Tetsuo Handa
1 sibling, 1 reply; 17+ messages in thread
From: Tetsuo Handa @ 2009-10-13 15:25 UTC (permalink / raw)
To: catalin.marinas; +Cc: paulmck, linux-kernel
Catalin Marinas wrote:
> > [ 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.
If what my guess shown below is correct,
(object_cache->slabp_cache->flags & SLAB_NOLEAKTRACE) == 0
is triggering recursive calls.
(1) Starting from create_object()
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/kmemleak.c#L507
(2) Calling kmem_cache_alloc() with (object_cache->flags & SLAB_NOLEAKTRACE) == SLAB_NOLEAKTRACE
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/kmemleak.c#L514
(3) Entering kmem_cache_alloc()
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/slab.c#L3550
(4) Calling __cache_alloc() with (object_cache->flags & SLAB_NOLEAKTRACE) == SLAB_NOLEAKTRACE
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/slab.c#L3552
(5) Entering __cache_alloc()
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/slab.c#L3379
(6) Calling __do_cache_alloc() with (object_cache->flags & SLAB_NOLEAKTRACE) == SLAB_NOLEAKTRACE
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/slab.c#L3393
(7) Entering __do_cache_alloc()
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/slab.c#L3347
(8) Calling ____cache_alloc() with (object_cache->flags & SLAB_NOLEAKTRACE) == SLAB_NOLEAKTRACE
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/slab.c#L3356
(9) Entering ____cache_alloc()
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/slab.c#L3091
(10) Calling cache_alloc_refill() with (object_cache->flags & SLAB_NOLEAKTRACE) == SLAB_NOLEAKTRACE
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/slab.c#L3105
(11) Entering cache_alloc_refill()
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/slab.c#L2924
(12) Calling cache_grow() with (object_cache->flags & SLAB_NOLEAKTRACE) == SLAB_NOLEAKTRACE
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/slab.c#L3001
(13) Entering cache_grow()
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/slab.c#L2728
(14) Calling alloc_slabmgmt() with (object_cache->flags & SLAB_NOLEAKTRACE) == SLAB_NOLEAKTRACE
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/slab.c#L2778
(15) Entering alloc_slabmgmt()
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/slab.c#L2569
(16) Calling kmem_cache_alloc_node() with (object_cache->slabp_cache->flags & SLAB_NOLEAKTRACE) == 0 ?
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/slab.c#L2577
(17) Entering kmem_cache_alloc_node()
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/include/linux/slab.h#L250
(18) Calling kmem_cache_alloc() with (object_cache->slabp_cache->flags & SLAB_NOLEAKTRACE) == 0 ?
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/include/linux/slab.h#L253
(19) Entering kmem_cache_alloc()
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/slab.c#L3550
(20) Calling __cache_alloc() with (object_cache->slabp_cache->flags & SLAB_NOLEAKTRACE) == 0 ?
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/slab.c#L3552
(21) Entering __cache_alloc()
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/slab.c#L3379
(22) Calling kmemleak_alloc_recursive() with (object_cache->slabp_cache->flags & SLAB_NOLEAKTRACE) == 0 ?
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/slab.c#L3396
(23) Entering kmemleak_alloc_recursive()
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/include/linux/kmemleak.h#L39
(24) Calling kmemleak_alloc() if (object_cache->slabp_cache->flags & SLAB_NOLEAKTRACE) == 0
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/include/linux/kmemleak.h#L44
(25) Entering kmemleak_alloc()
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/kmemleak.c#L853
(26) Calling create_object() again?
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/mm/kmemleak.c#L859
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [2.6.32-rc3 kmemleak] WARNING: atkernel/lockdep.c:3161check_flags+0xbe/0x180()
2009-10-13 15:25 ` [2.6.32-rc3 kmemleak] WARNING: atkernel/lockdep.c:3161check_flags+0xbe/0x180() Tetsuo Handa
@ 2009-10-14 11:55 ` Tetsuo Handa
2009-10-14 12:22 ` Catalin Marinas
0 siblings, 1 reply; 17+ messages in thread
From: Tetsuo Handa @ 2009-10-14 11:55 UTC (permalink / raw)
To: catalin.marinas; +Cc: paulmck, linux-kernel
Tetsuo Handa wrote:
> > 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.
> If what my guess shown below is correct,
> (object_cache->slabp_cache->flags & SLAB_NOLEAKTRACE) == 0
> is triggering recursive calls.
I applied below patch
--- linux-2.6.32-rc4/mm/slab.c 2009-10-14 16:22:44.962007072 +0900
+++ linux-2.6.32-rc4-ccs/mm/slab.c 2009-10-14 16:08:14.000000000 +0900
@@ -2573,6 +2573,8 @@
struct slab *slabp;
if (OFF_SLAB(cachep)) {
+ BUG_ON((cachep->flags & SLAB_NOLEAKTRACE) &&
+ !(cachep->slabp_cache->flags & SLAB_NOLEAKTRACE));
/* Slab management obj is off-slab. */
slabp = kmem_cache_alloc_node(cachep->slabp_cache,
local_flags, nodeid);
and verified that (cachep->slabp_cache->flags & SLAB_NOLEAKTRACE) == 0 is
triggering recursive call.
This is not locking related problem. This is stack overflow problem.
[ 0.000000] Linux version 2.6.32-rc4-ccs (root@tomoyo) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #2 SMP Wed Oct 14 16:09:02 JST 2009
(...snipped...)
[ 0.000000] -------------------------------------------------------
[ 0.000000] Good, all 218 testcases passed! |
[ 0.000000] ---------------------------------
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] kernel BUG at mm/slab.c:2577!
[ 0.000000] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
[ 0.000000] last sysfs file:
[ 0.000000] Modules linked in:
[ 0.000000]
[ 0.000000] Pid: 0, comm: swapper Not tainted (2.6.32-rc4-ccs #2) VMware Virtual Platform
[ 0.000000] EIP: 0060:[<c10cf0b1>] EFLAGS: 00010046 CPU: 0
[ 0.000000] EIP is at alloc_slabmgmt+0x81/0xa0
[ 0.000000] EAX: cf800200 EBX: 00000020 ECX: 00000000 EDX: 00800000
[ 0.000000] ESI: 00000000 EDI: cf837000 EBP: c14c4ec0 ESP: c14c4eb0
[ 0.000000] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 0.000000] Process swapper (pid: 0, ti=c14c4000 task=c14d7700 task.ti=c14c4000)
[ 0.000000] Stack:
[ 0.000000] 00000000 00000020 cf832bc0 cf804f30 c14c4ef0 c10cf4ee 00000020 00000000
[ 0.000000] <0> 00000000 cf804f54 00000020 00000000 00000000 00000000 cf832bc0 cf804f40
[ 0.000000] <0> c14c4f1c c10cfb0b cf837000 cf804f54 cf833f30 cf804f30 0000000c 00000020
[ 0.000000] Call Trace:
[ 0.000000] [<c10cf4ee>] ? cache_grow+0xae/0x170
[ 0.000000] [<c10cfb0b>] ? cache_alloc_refill+0x17b/0x210
[ 0.000000] [<c10d016a>] ? kmem_cache_alloc+0x1aa/0x1d0
[ 0.000000] [<c10d3a79>] ? create_object+0x29/0x220
[ 0.000000] [<c10d3a79>] ? create_object+0x29/0x220
[ 0.000000] [<c10d409a>] ? early_alloc+0x3a/0xe0
[ 0.000000] [<c10d40dc>] ? early_alloc+0x7c/0xe0
[ 0.000000] [<c10d409a>] ? early_alloc+0x3a/0xe0
[ 0.000000] [<c106e077>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c152ae62>] ? kmemleak_init+0xf2/0x180
[ 0.000000] [<c151096f>] ? start_kernel+0x18f/0x290
[ 0.000000] [<c15102c0>] ? unknown_bootoption+0x0/0x150
[ 0.000000] [<c1510095>] ? i386_start_kernel+0x65/0xa0
[ 0.000000] Code: 36 0f 00 00 89 c3 31 d2 8b 45 08 b9 08 00 00 00 89 04 24 89 d8 e8 60 66 26 00 31 c0 85 db 75 ab eb c9 8b 40 34 f6 40 1e 80 75 d1 <0f> 0b 8d b6 00 00 00 00 8d bc 27 00 00 00 00 eb fe 8d b4 26 00
[ 0.000000] EIP: [<c10cf0b1>] alloc_slabmgmt+0x81/0xa0 SS:ESP 0068:c14c4eb0
[ 0.000000] ---[ end trace 4eaa2a86a8e2da22 ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.000000] Pid: 0, comm: swapper Tainted: G D 2.6.32-rc4-ccs #2
[ 0.000000] Call Trace:
[ 0.000000] [<c10417ed>] ? printk+0x1d/0x30
[ 0.000000] [<c1040948>] panic+0x48/0x110
[ 0.000000] [<c1043f12>] do_exit+0x2b2/0x2d0
[ 0.000000] [<c1040cef>] ? print_oops_end_marker+0x2f/0x40
[ 0.000000] [<c1007508>] oops_end+0xb8/0xc0
[ 0.000000] [<c1007670>] die+0x60/0x80
[ 0.000000] [<c1003b63>] do_trap+0xb3/0xc0
[ 0.000000] [<c1003d10>] ? do_invalid_op+0x0/0xb0
[ 0.000000] [<c1003da0>] do_invalid_op+0x90/0xb0
[ 0.000000] [<c10cf0b1>] ? alloc_slabmgmt+0x81/0xa0
[ 0.000000] [<c10aa189>] ? get_page_from_freelist+0x139/0x2b0
[ 0.000000] [<c1349897>] ? error_code+0x67/0x70
[ 0.000000] [<c1003d10>] ? do_invalid_op+0x0/0xb0
[ 0.000000] [<c11bd82c>] ? trace_hardirqs_off_thunk+0xc/0x10
[ 0.000000] [<c134989b>] error_code+0x6b/0x70
[ 0.000000] [<c1003d10>] ? do_invalid_op+0x0/0xb0
[ 0.000000] [<c10cf0b1>] ? alloc_slabmgmt+0x81/0xa0
[ 0.000000] [<c10cf4ee>] cache_grow+0xae/0x170
[ 0.000000] [<c10cfb0b>] cache_alloc_refill+0x17b/0x210
[ 0.000000] [<c10d016a>] kmem_cache_alloc+0x1aa/0x1d0
[ 0.000000] [<c10d3a79>] ? create_object+0x29/0x220
[ 0.000000] [<c10d3a79>] create_object+0x29/0x220
[ 0.000000] [<c10d409a>] ? early_alloc+0x3a/0xe0
[ 0.000000] [<c10d40dc>] early_alloc+0x7c/0xe0
[ 0.000000] [<c10d409a>] ? early_alloc+0x3a/0xe0
[ 0.000000] [<c106e077>] ? trace_hardirqs_on_caller+0xf7/0x160
[ 0.000000] [<c152ae62>] kmemleak_init+0xf2/0x180
[ 0.000000] [<c151096f>] start_kernel+0x18f/0x290
[ 0.000000] [<c15102c0>] ? unknown_bootoption+0x0/0x150
[ 0.000000] [<c1510095>] i386_start_kernel+0x65/0xa0
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [2.6.32-rc3 kmemleak] WARNING: atkernel/lockdep.c:3161check_flags+0xbe/0x180()
2009-10-14 11:55 ` Tetsuo Handa
@ 2009-10-14 12:22 ` Catalin Marinas
2009-10-14 13:12 ` [2.6.32-rc3 kmemleak] WARNING:atkernel/lockdep.c:3161check_flags+0xbe/0x180() Tetsuo Handa
0 siblings, 1 reply; 17+ messages in thread
From: Catalin Marinas @ 2009-10-14 12:22 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: paulmck, linux-kernel
On Wed, 2009-10-14 at 20:55 +0900, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
> > > 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.
> > If what my guess shown below is correct,
> > (object_cache->slabp_cache->flags & SLAB_NOLEAKTRACE) == 0
> > is triggering recursive calls.
>
> I applied below patch
>
> --- linux-2.6.32-rc4/mm/slab.c 2009-10-14 16:22:44.962007072 +0900
> +++ linux-2.6.32-rc4-ccs/mm/slab.c 2009-10-14 16:08:14.000000000 +0900
> @@ -2573,6 +2573,8 @@
> struct slab *slabp;
>
> if (OFF_SLAB(cachep)) {
> + BUG_ON((cachep->flags & SLAB_NOLEAKTRACE) &&
> + !(cachep->slabp_cache->flags & SLAB_NOLEAKTRACE));
> /* Slab management obj is off-slab. */
> slabp = kmem_cache_alloc_node(cachep->slabp_cache,
> local_flags, nodeid);
>
> and verified that (cachep->slabp_cache->flags & SLAB_NOLEAKTRACE) == 0 is
> triggering recursive call.
> This is not locking related problem. This is stack overflow problem
I was looking at the same code but in my platform, OFF_SLAB(cachep) for
the kmemleak caches is always 0. I only added:
BUG_ON(cachep->flags & SLAB_NOLEAKTRACE);
and it never triggered but I need to enable more debugging features as
in your .config and re-run.
I assume you haven't modified the kmemleak.c file to increase the
MAX_TRACE size.
I don't think we should add SLAB_NOLEAKTRACE to slabmgmt since in theory
it should work. Is there a slabmgmt allocated for each
kmem_cache_alloc()? If yes, it will indeed get into infinite recursive
calls. If not, kmemleak should be able to cope though in some situations
it may still overflow.
Until I manage to reproduce the problem, could you please try the patch
below:
diff --git a/mm/slab.c b/mm/slab.c
index 7dfa481..f8f671b 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2263,7 +2263,8 @@ kmem_cache_create (const char *name, size_t size, size_t align,
* (bootstrapping cannot cope with offslab caches so don't do
* it too early on.)
*/
- if ((size >= (PAGE_SIZE >> 3)) && !slab_early_init)
+ if ((size >= (PAGE_SIZE >> 3)) && !slab_early_init &&
+ !(cachep->flags & SLAB_NOLEAKTRACE))
/*
* Size is large, assume best to place the slab management obj
* off-slab (should allow better packing of objs).
Thanks.
--
Catalin
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [2.6.32-rc3 kmemleak] WARNING:atkernel/lockdep.c:3161check_flags+0xbe/0x180()
2009-10-14 12:22 ` Catalin Marinas
@ 2009-10-14 13:12 ` Tetsuo Handa
2009-10-14 14:55 ` Catalin Marinas
0 siblings, 1 reply; 17+ messages in thread
From: Tetsuo Handa @ 2009-10-14 13:12 UTC (permalink / raw)
To: catalin.marinas; +Cc: paulmck, linux-kernel
Catalin Marinas wrote:
> Until I manage to reproduce the problem, could you please try the patch
> below:
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 7dfa481..f8f671b 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -2263,7 +2263,8 @@ kmem_cache_create (const char *name, size_t size, size_t align,
> * (bootstrapping cannot cope with offslab caches so don't do
> * it too early on.)
> */
> - if ((size >= (PAGE_SIZE >> 3)) && !slab_early_init)
> + if ((size >= (PAGE_SIZE >> 3)) && !slab_early_init &&
> + !(cachep->flags & SLAB_NOLEAKTRACE))
> /*
> * Size is large, assume best to place the slab management obj
> * off-slab (should allow better packing of objs).
It is "&& !(flags & SLAB_NOLEAKTRACE)" rather than
"&& !(cachep->flags & SLAB_NOLEAKTRACE)" because "cachep->flags = flags;" is
not yet done, isn't it?
After adding "&& !(flags & SLAB_NOLEAKTRACE)", I got out of memory error later.
[ 0.000000] Linux version 2.6.32-rc4 (root@tomoyo) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) #9 SMP Wed Oct 14 20:44:56 JST 2009
(...snipped...)
[ 0.000000] -------------------------------------------------------
[ 0.000000] Good, all 218 testcases passed! |
[ 0.000000] ---------------------------------
[ 0.000000] ODEBUG: selftest passed
[ 0.000000] TSC freq read from hypervisor : 2327.550 MHz
[ 0.000000] Detected 2327.550 MHz processor.
[ 0.008398] Calibrating delay loop (skipped), value calculated using timer frequency.. 4655.10 BogoMIPS (lpj=9310200)
[ 0.022680] Mount-cache hash table entries: 512
(...snipped...)
[ 7.578789] Initializing USB Mass Storage driver...
[ 7.582655] usbcore: registered new interface driver usb-storage
[ 7.584314] USB Mass Storage support registered.
[ 7.590848] PNP: No PS/2 controller found. Probing ports directly.
[ 8.295096] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 8.297408] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 8.312965] mice: PS/2 mouse device common for all mice
[ 8.925040] Kernel panic - not syncing: Out of memory and no killable processes...
[ 8.925045]
[ 8.927806] Pid: 139, comm: kseriod Not tainted 2.6.32-rc4 #9
[ 8.930156] Call Trace:
[ 8.930297] EISA: Probing bus 0 at eisa.0
[ 8.934031] [<c103bb1b>] panic+0x4b/0x110
[ 8.935244] [<c109dacf>] __out_of_memory+0x12f/0x130
[ 8.936652] [<c109db27>] out_of_memory+0x57/0xb0
[ 8.937936] [<c10a0730>] __alloc_pages_nodemask+0x5c0/0x600
[ 8.938986] TCP cubic registered
[ 8.939130] NET: Registered protocol family 17
[ 8.940733] Using IPI No-Shortcut mode
[ 8.944585] [<c10c29a0>] cache_alloc_refill+0x340/0x700
[ 8.946047] [<c10c24ff>] ? kmem_cache_alloc+0x5f/0x1c0
[ 8.948022] [<c10c2614>] kmem_cache_alloc+0x174/0x1c0
[ 8.949979] [<c10c71a9>] ? create_object+0x29/0x240
[ 8.951447] [<c10676b5>] ? mark_held_locks+0x55/0x70
[ 8.953261] [<c10c71a9>] create_object+0x29/0x240
[ 8.955636] [<c10c1b29>] ? poison_obj+0x29/0x50
[ 8.957248] [<c10c1686>] ? dbg_redzone1+0x16/0x30
[ 8.958518] [<c13076ba>] kmemleak_alloc+0x6a/0xe0
[ 8.959827] [<c1067954>] ? trace_hardirqs_on_caller+0x104/0x170
[ 8.961639] [<c10c3e50>] __kmalloc+0x1c0/0x230
[ 8.962890] [<c1191200>] ? kobject_get_path+0x50/0xe0
[ 8.964308] [<c1191200>] kobject_get_path+0x50/0xe0
[ 8.966717] [<c10676b5>] ? mark_held_locks+0x55/0x70
[ 8.968160] [<c1191a2d>] kobject_uevent_env+0x2dd/0x670
[ 8.969670] [<c1067954>] ? trace_hardirqs_on_caller+0x104/0x170
[ 8.971271] [<c10679cb>] ? trace_hardirqs_on+0xb/0x10
[ 8.972644] [<c11ed38c>] ? device_pm_add+0x7c/0x130
[ 8.973959] [<c1191dca>] kobject_uevent+0xa/0x10
[ 8.975240] [<c11e5dd2>] device_add+0x3a2/0x5c0
[ 8.977549] [<c1199118>] ? kvasprintf+0x48/0x60
[ 8.978781] [<c1190fba>] ? kobject_set_name_vargs+0x4a/0x60
[ 8.980303] [<c1264348>] input_register_device+0x88/0x1f0
[ 8.982355] [<c126871b>] atkbd_connect+0x21b/0x280
[ 8.983681] [<c131a59a>] ? mutex_lock_nested+0x3a/0x50
[ 8.985875] [<c125f5a0>] serio_connect_driver+0x30/0x50
[ 8.988324] [<c125f5d8>] serio_driver_probe+0x18/0x20
[ 8.990308] [<c11e8a90>] driver_probe_device+0xa0/0x290
[ 8.991910] [<c11e8eea>] __driver_attach+0x7a/0x80
[ 8.993823] [<c11e7ef9>] bus_for_each_dev+0x49/0x70
[ 8.995192] [<c11e889e>] driver_attach+0x1e/0x20
[ 8.998043] [<c11e8e70>] ? __driver_attach+0x0/0x80
[ 8.999406] [<c1260363>] serio_thread+0x2b3/0x320
[ 9.001158] [<c1054e20>] ? autoremove_wake_function+0x0/0x50
[ 9.002699] [<c12600b0>] ? serio_thread+0x0/0x320
[ 9.004027] [<c1054bb4>] kthread+0x74/0x80
[ 9.005492] [<c1054b40>] ? kthread+0x0/0x80
[ 9.006651] [<c1003897>] kernel_thread_helper+0x7/0x10
> I don't think we should add SLAB_NOLEAKTRACE to slabmgmt since in theory
> it should work. Is there a slabmgmt allocated for each
> kmem_cache_alloc()? If yes, it will indeed get into infinite recursive
> calls. If not, kmemleak should be able to cope though in some situations
> it may still overflow.
Will you tell me how to check it? (Some /proc file?)
Regards.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [2.6.32-rc3 kmemleak] WARNING:atkernel/lockdep.c:3161check_flags+0xbe/0x180()
2009-10-14 13:12 ` [2.6.32-rc3 kmemleak] WARNING:atkernel/lockdep.c:3161check_flags+0xbe/0x180() Tetsuo Handa
@ 2009-10-14 14:55 ` Catalin Marinas
2009-10-14 21:50 ` [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161 check_flags+0xbe/0x180() Tetsuo Handa
2009-10-15 3:52 ` Tetsuo Handa
0 siblings, 2 replies; 17+ messages in thread
From: Catalin Marinas @ 2009-10-14 14:55 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: paulmck, linux-kernel
On Wed, 2009-10-14 at 22:12 +0900, Tetsuo Handa wrote:
> Catalin Marinas wrote:
> > Until I manage to reproduce the problem, could you please try the patch
> > below:
> >
> > diff --git a/mm/slab.c b/mm/slab.c
> > index 7dfa481..f8f671b 100644
> > --- a/mm/slab.c
> > +++ b/mm/slab.c
> > @@ -2263,7 +2263,8 @@ kmem_cache_create (const char *name, size_t size, size_t align,
> > * (bootstrapping cannot cope with offslab caches so don't do
> > * it too early on.)
> > */
> > - if ((size >= (PAGE_SIZE >> 3)) && !slab_early_init)
> > + if ((size >= (PAGE_SIZE >> 3)) && !slab_early_init &&
> > + !(cachep->flags & SLAB_NOLEAKTRACE))
> > /*
> > * Size is large, assume best to place the slab management obj
> > * off-slab (should allow better packing of objs).
>
> It is "&& !(flags & SLAB_NOLEAKTRACE)" rather than
> "&& !(cachep->flags & SLAB_NOLEAKTRACE)" because "cachep->flags = flags;" is
> not yet done, isn't it?
Yes, thanks.
> After adding "&& !(flags & SLAB_NOLEAKTRACE)", I got out of memory error later.
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.
If that's the case, my patch is still correct to avoid the recursive
call but OOM is quite plausible (every object allocated needs another
page for the kmemleak metadata).
> > I don't think we should add SLAB_NOLEAKTRACE to slabmgmt since in theory
> > it should work. Is there a slabmgmt allocated for each
> > kmem_cache_alloc()? If yes, it will indeed get into infinite recursive
> > calls. If not, kmemleak should be able to cope though in some situations
> > it may still overflow.
>
> Will you tell me how to check it? (Some /proc file?)
Looking at the code, it seems that with off slab mgmt data, it allocates
one slabmgmt object per kmem_cache_alloc() call. The slabp_cache is set
to one of the general cachep which are also used by kmalloc, so we can't
really set SLAB_NOLEAKTRACE on them.
Regards.
--
Catalin
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161 check_flags+0xbe/0x180()
2009-10-14 14:55 ` Catalin Marinas
@ 2009-10-14 21:50 ` Tetsuo Handa
2009-10-15 3:52 ` Tetsuo Handa
1 sibling, 0 replies; 17+ messages in thread
From: Tetsuo Handa @ 2009-10-14 21:50 UTC (permalink / raw)
To: catalin.marinas; +Cc: paulmck, linux-kernel
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.
OK. I'll check it later.
> >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.
>
> If that's the case, my patch is still correct to avoid the recursive
> call but OOM is quite plausible (every object allocated needs another
> page for the kmemleak metadata).
Indeed. After applying http://lkml.org/lkml/2009/10/14/235 ,
I increased RAM from 512MB to 1736MB, and the system booted without OOM.
[ 8.381581] kmemleak: Kernel memory leak detector initialized
[ 8.436724] kmemleak: Automatic memory scanning thread started
[ 88.765791] kmemleak: 275 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
I get some reports from /sys/kernel/debug/kmemleak .
unreferenced object 0xf703a430 (size 24):
comm "swapper", pid 0, jiffies 4294892296
hex dump (first 24 bytes):
00 00 00 00 00 a4 03 f7 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 ........
backtrace:
[<c10c7260>] create_object+0xe0/0x240
[<c13076ba>] kmemleak_alloc+0x6a/0xe0
[<c10c25d8>] kmem_cache_alloc+0x138/0x1c0
[<c14c42c6>] debug_objects_mem_init+0x86/0x520
[<c14a57c2>] start_kernel+0x232/0x340
[<c14a507f>] i386_start_kernel+0x7f/0xb0
[<ffffffff>] 0xffffffff
unreferenced object 0xce8d6850 (size 24):
comm "hald", pid 3483, jiffies 4294905535
hex dump (first 24 bytes):
00 00 00 00 f8 74 c4 c1 02 00 00 00 c4 59 49 c1 .....t.......YI.
84 95 47 c1 00 00 00 00 ..G.....
backtrace:
[<c10c7260>] create_object+0xe0/0x240
[<c13076ba>] kmemleak_alloc+0x6a/0xe0
[<c10c25d8>] kmem_cache_alloc+0x138/0x1c0
[<c11a699d>] __debug_object_init+0x22d/0x2e0
[<c11a6a97>] debug_object_init+0x17/0x20
[<c1047c74>] init_timer_key+0x24/0x70
[<c127c012>] sock_init_data+0xb2/0x220
[<c12e6388>] unix_create1+0x78/0x160
[<c12e820a>] unix_stream_connect+0x6a/0x3b0
[<c1279ef2>] sys_connect+0x62/0x90
[<c127a5d8>] sys_socketcall+0xb8/0x270
[<c1002d38>] sysenter_do_call+0x12/0x36
[<ffffffff>] 0xffffffff
unreferenced object 0xd49e8b78 (size 32):
comm "insmod", pid 985, jiffies 4294894679
hex dump (first 32 bytes):
30 3a 30 3a 31 35 3a 30 00 5a 5a 5a 5a 5a 5a 5a 0:0:15:0.ZZZZZZZ
5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a a5 ZZZZZZZZZZZZZZZ.
backtrace:
[<c10c7260>] create_object+0xe0/0x240
[<c13076ba>] kmemleak_alloc+0x6a/0xe0
[<c10c3e50>] __kmalloc+0x1c0/0x230
[<c1199105>] kvasprintf+0x35/0x60
[<c1190f91>] kobject_set_name_vargs+0x21/0x60
[<c11e476f>] dev_set_name+0x1f/0x30
[<c12161be>] scsi_sysfs_device_initialize+0xbe/0x120
[<c1212d39>] scsi_alloc_sdev+0x189/0x210
[<c1212e9b>] scsi_probe_and_add_lun+0xdb/0xc10
[<c12140dc>] __scsi_scan_target+0xdc/0x680
[<c12146fc>] scsi_scan_channel+0x7c/0x90
[<c121479b>] scsi_scan_host_selected+0x8b/0x150
[<c12148d9>] do_scsi_scan_host+0x79/0x80
[<c1214ba3>] scsi_scan_host+0x163/0x200
[<f809656c>] mptspi_probe+0x37c/0x400 [mptspi]
[<c11b4583>] local_pci_probe+0x13/0x20
Regards.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161 check_flags+0xbe/0x180()
2009-10-14 14:55 ` Catalin Marinas
2009-10-14 21:50 ` [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161 check_flags+0xbe/0x180() Tetsuo Handa
@ 2009-10-15 3:52 ` Tetsuo Handa
2009-10-15 8:45 ` Catalin Marinas
1 sibling, 1 reply; 17+ messages in thread
From: Tetsuo Handa @ 2009-10-15 3:52 UTC (permalink / raw)
To: catalin.marinas; +Cc: paulmck, linux-kernel
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161 check_flags+0xbe/0x180()
2009-10-15 3:52 ` Tetsuo Handa
@ 2009-10-15 8:45 ` Catalin Marinas
0 siblings, 0 replies; 17+ messages in thread
From: Catalin Marinas @ 2009-10-15 8:45 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: paulmck, linux-kernel
On Thu, 2009-10-15 at 12:52 +0900, Tetsuo Handa wrote:
> 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);
I think it would be better to disable kmemleak than panicking.
> Don't we need to disable kmemleak routine (call kmemleak_disable()?)
> when early_alloc() failed in order to avoid false positives?
This is already done in create_object() via kmemleak_stop().
> I got below entries.
> (Similar entries are posted at http://lkml.org/lkml/2009/10/14/571 )
As a general rule with kmemleak, it would be useful to run a few "echo
scan > /sys/kernel/debug/kmemleak" to make sure they are not just
transient false positives.
> 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
I get these reports as well and I think they are false positives. I
looked at the code in question and couldn't figure out why kmemleak is
confused.
> 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?
Yes, they are just some transient memory leaks. This is usually caused
by the fact that kmemleak doesn't stop the allocations when scanning
(many garbage collectors do this). There are very few cases of false
positives left and debug_objects is one of them
Thanks.
--
Catalin
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2009-10-15 8:46 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-05 3:15 [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161 check_flags+0xbe/0x180() Tetsuo Handa
2009-10-05 8:55 ` Catalin Marinas
2009-10-07 15:51 ` Paul E. McKenney
2009-10-08 12:34 ` [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161check_flags+0xbe/0x180() Tetsuo Handa
2009-10-08 12:42 ` Catalin Marinas
2009-10-13 3:17 ` Tetsuo Handa
2009-10-13 12:00 ` Catalin Marinas
2009-10-13 12:57 ` [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161 check_flags+0xbe/0x180() Tetsuo Handa
2009-10-13 15:25 ` [2.6.32-rc3 kmemleak] WARNING: atkernel/lockdep.c:3161check_flags+0xbe/0x180() Tetsuo Handa
2009-10-14 11:55 ` Tetsuo Handa
2009-10-14 12:22 ` Catalin Marinas
2009-10-14 13:12 ` [2.6.32-rc3 kmemleak] WARNING:atkernel/lockdep.c:3161check_flags+0xbe/0x180() Tetsuo Handa
2009-10-14 14:55 ` Catalin Marinas
2009-10-14 21:50 ` [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161 check_flags+0xbe/0x180() Tetsuo Handa
2009-10-15 3:52 ` Tetsuo Handa
2009-10-15 8:45 ` Catalin Marinas
2009-10-08 12:39 ` Catalin Marinas
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.