Messages in this thread | | | Date | Thu, 13 Jul 2006 15:27:06 -0700 (PDT) | From | Christoph Lameter <> | Subject | Re: [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/
| |