From: Srivatsa Vaddagiri <vatsa@in.ibm.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>,
Benjamin Gilbert <bgilbert@cs.cmu.edu>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Gautham shenoy <ego@in.ibm.com>, Andrew Morton <akpm@osdl.org>,
Pekka Enberg <penberg@cs.helsinki.fi>
Subject: Re: [patch -mm] slab: use CPU_LOCK_[ACQUIRE|RELEASE]
Date: Thu, 11 Jan 2007 08:00:05 +0530 [thread overview]
Message-ID: <20070111023005.GA5357@in.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0701101012460.21379@schroedinger.engr.sgi.com>
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
next prev parent reply other threads:[~2007-01-11 2:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-08 17:07 Failure to release lock after CPU hot-unplug canceled Benjamin Gilbert
2007-01-09 12:17 ` Heiko Carstens
2007-01-09 12:27 ` Srivatsa Vaddagiri
2007-01-09 15:03 ` Heiko Carstens
2007-01-09 15:05 ` [patch -mm] call cpu_chain with CPU_DOWN_FAILED if CPU_DOWN_PREPARE failed Heiko Carstens
2007-01-09 15:06 ` [patch -mm] slab: use CPU_LOCK_[ACQUIRE|RELEASE] Heiko Carstens
2007-01-10 18:20 ` Christoph Lameter
2007-01-11 2:30 ` Srivatsa Vaddagiri [this message]
2007-01-09 16:34 ` Failure to release lock after CPU hot-unplug canceled Benjamin Gilbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070111023005.GA5357@in.ibm.com \
--to=vatsa@in.ibm.com \
--cc=akpm@osdl.org \
--cc=bgilbert@cs.cmu.edu \
--cc=clameter@sgi.com \
--cc=ego@in.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=penberg@cs.helsinki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.