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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/