* [PATCH V2 1/2] cpufreq: unlock correct rwsem while updating policy->cpu
@ 2013-09-17 4:52 Viresh Kumar
2013-09-17 9:24 ` Jon Medhurst (Tixy)
0 siblings, 1 reply; 2+ messages in thread
From: Viresh Kumar @ 2013-09-17 4:52 UTC (permalink / raw)
To: rjw
Cc: linaro-kernel, patches, cpufreq, linux-pm, linux-kernel,
srivatsa.bhat, tixy, Viresh Kumar
Current code looks like this:
WARN_ON(lock_policy_rwsem_write(cpu));
update_policy_cpu(policy, new_cpu);
unlock_policy_rwsem_write(cpu);
{lock|unlock}_policy_rwsem_write(cpu) takes/releases policy->cpu's rwsem.
Because cpu is changing with the call to update_policy_cpu(), the
unlock_policy_rwsem_write() will release the incorrect lock.
The right solution would be to release the same lock as was taken earlier. Also
update_policy_cpu() was also called from cpufreq_add_dev() without any locks and
so its better if we move this locking to inside update_policy_cpu().
Reported-and-Tested-by: Jon Medhurst<tixy@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
Hi Rafael,
Only one patch is sent now as other one is unchanged.
drivers/cpufreq/cpufreq.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 43c24aa..1479522 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -952,9 +952,20 @@ static void update_policy_cpu(struct cpufreq_policy *policy, unsigned int cpu)
if (cpu == policy->cpu)
return;
+ /*
+ * Take direct locks as lock_policy_rwsem_write wouldn't work here.
+ * Also lock for last cpu is enough here as contention will happen only
+ * after policy->cpu is changed and after it is changed, other threads
+ * will try to acquire lock for new cpu. And policy is already updated
+ * by then.
+ */
+ down_write(&per_cpu(cpu_policy_rwsem, policy->cpu));
+
policy->last_cpu = policy->cpu;
policy->cpu = cpu;
+ up_write(&per_cpu(cpu_policy_rwsem, policy->last_cpu));
+
#ifdef CONFIG_CPU_FREQ_TABLE
cpufreq_frequency_table_update_policy_cpu(policy);
#endif
@@ -1203,9 +1214,7 @@ static int __cpufreq_remove_dev_prepare(struct device *dev,
new_cpu = cpufreq_nominate_new_policy_cpu(policy, cpu, frozen);
if (new_cpu >= 0) {
- WARN_ON(lock_policy_rwsem_write(cpu));
update_policy_cpu(policy, new_cpu);
- unlock_policy_rwsem_write(cpu);
if (!frozen) {
pr_debug("%s: policy Kobject moved to cpu: %d "
--
1.7.12.rc2.18.g61b472e
^ permalink raw reply related [flat|nested] 2+ messages in thread* Re: [PATCH V2 1/2] cpufreq: unlock correct rwsem while updating policy->cpu
2013-09-17 4:52 [PATCH V2 1/2] cpufreq: unlock correct rwsem while updating policy->cpu Viresh Kumar
@ 2013-09-17 9:24 ` Jon Medhurst (Tixy)
0 siblings, 0 replies; 2+ messages in thread
From: Jon Medhurst (Tixy) @ 2013-09-17 9:24 UTC (permalink / raw)
To: Viresh Kumar
Cc: rjw, linaro-kernel, patches, cpufreq, linux-pm, linux-kernel,
srivatsa.bhat
On Tue, 2013-09-17 at 10:22 +0530, Viresh Kumar wrote:
> Current code looks like this:
>
> WARN_ON(lock_policy_rwsem_write(cpu));
> update_policy_cpu(policy, new_cpu);
> unlock_policy_rwsem_write(cpu);
>
> {lock|unlock}_policy_rwsem_write(cpu) takes/releases policy->cpu's rwsem.
> Because cpu is changing with the call to update_policy_cpu(), the
> unlock_policy_rwsem_write() will release the incorrect lock.
>
> The right solution would be to release the same lock as was taken earlier. Also
> update_policy_cpu() was also called from cpufreq_add_dev() without any locks and
> so its better if we move this locking to inside update_policy_cpu().
>
> Reported-and-Tested-by: Jon Medhurst<tixy@linaro.org>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> Hi Rafael,
>
> Only one patch is sent now as other one is unchanged.
This patch fixes a regression introduced in 3.12 by commit f9ba680d23
(cpufreq: Extract the handover of policy cpu to a helper function).
The other patch is a tidyup of long-standing code.
> drivers/cpufreq/cpufreq.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 43c24aa..1479522 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -952,9 +952,20 @@ static void update_policy_cpu(struct cpufreq_policy *policy, unsigned int cpu)
> if (cpu == policy->cpu)
> return;
>
> + /*
> + * Take direct locks as lock_policy_rwsem_write wouldn't work here.
> + * Also lock for last cpu is enough here as contention will happen only
> + * after policy->cpu is changed and after it is changed, other threads
> + * will try to acquire lock for new cpu. And policy is already updated
> + * by then.
> + */
> + down_write(&per_cpu(cpu_policy_rwsem, policy->cpu));
> +
> policy->last_cpu = policy->cpu;
> policy->cpu = cpu;
>
> + up_write(&per_cpu(cpu_policy_rwsem, policy->last_cpu));
> +
> #ifdef CONFIG_CPU_FREQ_TABLE
> cpufreq_frequency_table_update_policy_cpu(policy);
> #endif
> @@ -1203,9 +1214,7 @@ static int __cpufreq_remove_dev_prepare(struct device *dev,
>
> new_cpu = cpufreq_nominate_new_policy_cpu(policy, cpu, frozen);
> if (new_cpu >= 0) {
> - WARN_ON(lock_policy_rwsem_write(cpu));
> update_policy_cpu(policy, new_cpu);
> - unlock_policy_rwsem_write(cpu);
>
> if (!frozen) {
> pr_debug("%s: policy Kobject moved to cpu: %d "
--
Tixy
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-09-17 9:24 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-17 4:52 [PATCH V2 1/2] cpufreq: unlock correct rwsem while updating policy->cpu Viresh Kumar
2013-09-17 9:24 ` Jon Medhurst (Tixy)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).