On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
> I don't see how this circular locking dependency can occur.. If you are using
> SLUB,
> kmem_cache_destroy() releases slab_mutex before it calls rcu_barrier(). If
> you are
> using SLAB, kmem_cache_destroy() wraps its whole operation inside
> get/put_online_cpus(),
> which means, it cannot run concurrently with a hotplug operation such as
> cpu_up(). So, I'm
> rather puzzled at this lockdep splat..
I am using SLAB here.
The scenario I think is very well possible:
CPU 0 CPU 1
kmem_cache_destroy()
mutex_lock(slab_mutex)
_cpu_up()
cpu_hotplug_begin()
mutex_lock(cpu_hotplug.lock)
rcu_barrier()
_rcu_barrier()
get_online_cpus()
mutex_lock(cpu_hotplug.lock)
(blocks, CPU 1 has the mutex)
__cpu_notify()
mutex_lock(slab_mutex)
Deadlock.
Right?
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
