Messages in this thread | | | Date | Thu, 13 Jul 2006 21:55:46 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] lockdep: annotate mm/slab.c |
| |
* Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> Hi, > > On 7/13/06, Ingo Molnar <mingo@elte.hu> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |