kpriv/linux-hardened
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

[PATCH] Fix cpufreq vs hotplug lockdep recursion.

Browse source 
[ 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>
This commit is contained in:
Dave Jones 2006-07-07 12:31:27 -04:00 committed by Linus Torvalds
parent 120bda20c6
commit a496e25dfb
1 changed files with 4 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
drivers/cpufreq/cpufreq.c
View file

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