lkml.org 
[lkml]   [2006]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] lockdep: annotate mm/slab.c
On Thu, 13 Jul 2006, Arjan van de Ven wrote:

> there is a corner case in the slab code that I personally don't trust at
> all. In the NUMA case, if the memory is not originally from your own
> node, the cache_free_alien() function takes, while having your own local
> lock, the lock of the remote node as well. (at least on my reading of
> the code) to free the memory to that node. I have yet to see where in
> the code it safeguards against that remote node doing the exact same
> thing in the opposite direction concurrently, and causing a basic ABBA
> deadlock.

Hmmm.. This case is only followed during bootup when we do not have
alien caches yet. And its pretty rare to free memory on bootup. Once the
alien caches are present then we do not take the listlock anymore but
use the lock of the alien structure.

This could cause an ABBA deadlock if a free happens on another
processor during bootup before all the slabs are established.

That then brings us to look if a slab free can happen before a slab is
completely established via kmem_cache_create.

kmem_cache_create takes the cpu hotplug lock and the cache_chain_mutex.

One could argue that a subsystem must make sure that the slab cache it
creates should not be used before kmem_cache_create is complete?

Alokk: Do we really need to check for alien caches not present there?


-
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/

\
 
 \ /
  Last update: 2006-07-14 00:31    [from the cache]
©2003-2011 Jasper Spaans