On 19 March 2014 17:45, Srivatsa S. Bhat srivatsa.bhat@linux.vnet.ibm.com wrote:
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 199b52b..e90388f 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -349,6 +349,38 @@ void cpufreq_notify_post_transition(struct cpufreq_policy *policy, EXPORT_SYMBOL_GPL(cpufreq_notify_post_transition);
+void cpufreq_freq_transition_begin(struct cpufreq_policy *policy,
struct cpufreq_freqs *freqs, unsigned int state)
+{ +wait:
wait_event(&policy->transition_wait, !policy->transition_ongoing);
I think its broken here. At this point another thread can come take lock, update transition_ongoing, send notification and finally unlock..
And after that we can take the lock and send another notification..
Correct?
if (!mutex_trylock(&policy->transition_lock))
goto wait;
policy->transition_ongoing++;
s/++/ = true
cpufreq_notify_transition(policy, freqs, CPUFREQ_PRECHANGE);
mutex_unlock(&policy->transition_lock);
We can release the lock before sending notifications, its there just to protect transition_ongoing.