Messages in this thread | | | Date | Tue, 2 Jun 2015 11:41:33 +0530 | From | Viresh Kumar <> | Subject | Re: [RFC PATCH] cpufreq/hotplug: Fix cpu-hotplug cpufreq race conditions |
| |
On 02-06-15, 11:33, Preeti U Murthy wrote: > No, dbs_data is a governor wide data structure and not a policy wide
Yeah, that's the common part which I was referring to. But normally its just read for policies in START/STOP, they just update per-cpu data for policy->cpus.
> one, which is manipulated in START/STOP calls for drivers where the > CPUFREQ_HAVE_GOVERNOR_PER_POLICY is not set. > > So even if we assume that we hold per-policy locks, the following race > is still present. Assume that we have just two cpus which do not have a > governor-per-policy set. > > CPU0 CPU1 > > store* store* > > lock(policy 1) lock(policy 2) > cpufreq_set_policy() cpufreq_set_policy() > EXIT() : > dbs-data->usage_count-- > > INIT() > dbs_data exists
You missed the usage_count++ here.
> so return > EXIT() > dbs_data->usage_count -- = 0 > kfree(dbs_data)
And so this shouldn't happen. Else we are missing locking in governor's code, rather than cpufreq.c
-- viresh
| |