| Message ID | 63ac1edc637ef2c8cf05579972506ad5365948c1.1379393377.git.viresh.kumar@linaro.org |
|---|---|
| State | New |
| Headers | show |
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 "
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 "
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(-)