[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>

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 1ba4039..8d32818 100644 (file)
--- 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;
 }