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

[Alok kataria]

Hi,
On 7/13/06, Christoph Lameter <clameter@xxxxxxx> 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@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/