Re: [patch] lockdep: annotate mm/slab.c

[Ingo Molnar]

* Pekka Enberg <penberg@xxxxxxxxxxxxxx> wrote:

> Hi,
> 
> On 7/13/06, Ingo Molnar <mingo@xxxxxxx> wrote:
> >mm/slab.c uses nested locking when dealing with 'off-slab'
> >caches, in that case it allocates the slab header from the
> >(on-slab) kmalloc caches. Teach the lock validator about
> >this by putting all on-slab caches into a separate class.
> 
> Which lock is that? This affects only caches that cache_grow() use, so 
> we are really only interested in annotating kmalloc() on-slab caches 
> (like in the patch), not _all_, right?

it's ->list_lock, and a sample nesting scenario is:

 [<c013a9a8>] lock_acquire+0x78/0xa0
 [<c0313e5a>] _spin_lock_nested+0x2a/0x40
 [<c0163024>] __cache_free+0x484/0x5c0
 [<c01632ad>] slab_destroy+0x14d/0x1e0
 [<c0162ac9>] free_block+0x189/0x1e0
 [<c01630f4>] __cache_free+0x554/0x5c0
 [<c0163653>] kmem_cache_free+0x73/0xc0
 [<c016a24f>] file_free_rcu+0xf/0x20
 [<c0130755>] __rcu_process_callbacks+0x75/0x1b0
 [<c0130bc7>] rcu_process_callbacks+0x27/0x50
 [<c0123f3a>] tasklet_action+0x6a/0xf0
 [<c012413b>] __do_softirq+0x8b/0x130
 [<c0106ba3>] do_softirq+0x73/0x100

(the off-slab nesting is perfectly correct locking code AFAICS - it just 
needs to be taught to lockdep - which the patch does. OTOH i'm less sure 
about the NUMA alien-cache-draining nesting.)

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/