Commit a496e25d authored by Dave Jones's avatar Dave Jones Committed by Linus Torvalds

[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: default avatarArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: default avatarDave Jones <davej@redhat.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
parent 120bda20
......@@ -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;
}
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment