Re: .2356 and circular dependency.....

[Arjan van de Ven <arjan fenrus demon nl>]

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 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;
 }