mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-29 19:21:31 -04:00
[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 <[email protected]>
Signed-off-by: Dave Jones <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
This commit is contained in:
parent
120bda20c6
commit
a496e25dfb
1 changed files with 4 additions and 0 deletions
|
|
@ -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;
|
||||
}
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue