From a496e25dfb25493a57bcee5d66875d6ff80a9093 Mon Sep 17 00:00:00 2001 From: Dave Jones Date: Fri, 7 Jul 2006 12:31:27 -0400 Subject: [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: [] mutex_lock+0x21/0x24 > > but task is already holding lock: > (cpucontrol){--..}, at: [] 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 Signed-off-by: Dave Jones Signed-off-by: Linus Torvalds --- drivers/cpufreq/cpufreq.c | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'drivers/cpufreq') diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 1ba4039777e8..8d328186f774 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; } -- cgit v1.2.3