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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux