Messages in this thread | | | Date | Thu, 11 Jan 2007 08:00:05 +0530 | From | Srivatsa Vaddagiri <> | Subject | Re: [patch -mm] slab: use CPU_LOCK_[ACQUIRE|RELEASE] |
| |
On Wed, Jan 10, 2007 at 10:20:28AM -0800, Christoph Lameter wrote: > I have got a bad feeling about upcoming deadlock problems when looking at > the mutex_lock / unlock code in cpuup_callback in slab.c. Branches > that just obtain a lock or release a lock? I hope there is some > control of what happens between lock acquisition and release?
A cpu hotplug should happen between LOCK_ACQUIRE/RELEASE
> You are aware that this lock is taken for cache shrinking/destroy, tuning > of cpu cache sizes, proc output and cache creation? Any of those run on > the same processor should cause a deadlock.
Why? mutex_lock() taken in LOCK_ACQ will just block those functions (cache create etc) from proceeding simultaneously as a hotplug event. This per-subsystem mutex_lock() is supposed to be a replacement for the global lock_cpu_hotplug() lock ..
But the whole thing is changing again ..we will likely move towards a process freezer based cpu hotplug locking ..all the lock_cpu_hotplugs() and the existing LOCK_ACQ/RELS can go away when we do that ..
-- Regards, vatsa - 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/
| |