Re: [PATCH v2] cpufreq: Fix timer/workqueue corruption by protecting reading governor_enabled

2014-01-02 Thread Jane Li
On 01/03/2014 07:26 AM, Dmitry Torokhov wrote Unlocking in different branches is not the best practice IMO, I'd recommend doing: mutex_lock(&cpufreq_governor_lock); if (!policy->governor_enabled) goto out_unlock; ... out_unlock: mutex_unlock(&c

Re: [PATCH v2] cpufreq: Fix timer/workqueue corruption by protecting reading governor_enabled

2014-01-02 Thread Dmitry Torokhov
Hi Jane: On Thu, Jan 02, 2014 at 11:14:42AM +0800, j...@marvell.com wrote: > @@ -119,8 +121,11 @@ void gov_queue_work(struct dbs_data *dbs_data, struct > cpufreq_policy *policy, > { > int i; > > - if (!policy->governor_enabled) > + mutex_lock(&cpufreq_governor_lock); > + if (

Re: [PATCH v2] cpufreq: Fix timer/workqueue corruption by protecting reading governor_enabled

2014-01-01 Thread Viresh Kumar
On 2 January 2014 08:44, wrote: > From: Jane Li > > When a CPU is hot removed we'll cancel all the delayed work items via > gov_cancel_work(). Sometimes the delayed work function determines that > it should adjust the delay for all other CPUs that the policy is > managing. If this scenario occur

[PATCH v2] cpufreq: Fix timer/workqueue corruption by protecting reading governor_enabled

2014-01-01 Thread jiel
From: Jane Li When a CPU is hot removed we'll cancel all the delayed work items via gov_cancel_work(). Sometimes the delayed work function determines that it should adjust the delay for all other CPUs that the policy is managing. If this scenario occurs, the canceling CPU will cancel its own work