Messages in this thread | | | Date | Thu, 13 Jul 2006 16:08:17 -0700 | From | "Alok kataria" <> | Subject | Re: [patch] lockdep: annotate mm/slab.c |
| |
Hi, On 7/13/06, Christoph Lameter <clameter@sgi.com> wrote: > 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. >
Christoph, IMO even then we wont deadlock, because in the case of a remote free when there are no alien caches, we simply take the remote node's list_lock and free the object, directly in the remote slab.
> 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? >
Yes we do need to, there can be a case when all cpu's of a node have gone down, we free the alien cache, and this alien cache might have come from this cache itself, (see cpuup_callback). In this case we will find the alien caches to be absent and then we will directly free to the remote nodes slab.
Thanks & Regards, Alok > > - > 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/ >
-- A computer scientist is someone who, when told to "Go to Hell," sees the "go to," rather than the destination, as harmful.
Alok Kataria - 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/
| |