.2356 and circular dependency.....
Arjan van de Ven
arjan at fenrus.demon.nl
Fri Jul 7 11:54:38 UTC 2006
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.
>
this patch should fix this one
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 at linux.intel.com>
---
drivers/cpufreq/cpufreq.c | 4 ++++
1 file changed, 4 insertions(+)
Index: linux-2.6.18-rc1/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-2.6.18-rc1.orig/drivers/cpufreq/cpufreq.c
+++ linux-2.6.18-rc1/drivers/cpufreq/cpufreq.c
@@ -423,6 +423,8 @@ static ssize_t store_scaling_governor (s
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 (s
policy->user_policy.governor = policy->governor;
mutex_unlock(&policy->lock);
+ unlock_cpu_hotplug();
+
return ret ? ret : count;
}
More information about the fedora-test-list
mailing list