diff options
author | Dave Jones <davej@redhat.com> | 2006-07-07 12:31:27 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-07-07 09:46:45 -0700 |
commit | a496e25dfb25493a57bcee5d66875d6ff80a9093 (patch) | |
tree | e0dc7f0f8151f6cf0ddc9ef987a6750e4e4a9ea3 /drivers/cpufreq | |
parent | 120bda20c6f64b32e8bfbdd7b34feafaa5f5332e (diff) | |
download | kernel_samsung_tuna-a496e25dfb25493a57bcee5d66875d6ff80a9093.zip kernel_samsung_tuna-a496e25dfb25493a57bcee5d66875d6ff80a9093.tar.gz kernel_samsung_tuna-a496e25dfb25493a57bcee5d66875d6ff80a9093.tar.bz2 |
[PATCH] Fix cpufreq vs hotplug lockdep recursion.
[ There's some not quite baked bits in cpufreq-git right now
so sending this on as a patch instead ]
On Thu, 2006-07-06 at 07:58 -0700, Tom London wrote:
> After installing .2356 I get this each time I boot:
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> -------------------------------------------------------
> S06cpuspeed/1620 is trying to acquire lock:
> (dbs_mutex){--..}, at: [<c060d6bb>] mutex_lock+0x21/0x24
>
> but task is already holding lock:
> (cpucontrol){--..}, at: [<c060d6bb>] mutex_lock+0x21/0x24
>
> which lock already depends on the new lock.
>
make sure the cpu hotplug recursive mutex (yuck) is taken early in the
cpufreq codepaths to avoid a AB-BA deadlock.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'drivers/cpufreq')
-rw-r--r-- | drivers/cpufreq/cpufreq.c | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 1ba4039..8d32818 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -423,6 +423,8 @@ static ssize_t store_scaling_governor (struct cpufreq_policy * policy, if (cpufreq_parse_governor(str_governor, &new_policy.policy, &new_policy.governor)) return -EINVAL; + lock_cpu_hotplug(); + /* Do not use cpufreq_set_policy here or the user_policy.max will be wrongly overridden */ mutex_lock(&policy->lock); @@ -432,6 +434,8 @@ static ssize_t store_scaling_governor (struct cpufreq_policy * policy, policy->user_policy.governor = policy->governor; mutex_unlock(&policy->lock); + unlock_cpu_hotplug(); + return ret ? ret : count; } |