On Wed, Jun 26, 2013 at 08:02:29PM +0530, Viresh Kumar wrote: > On 26 June 2013 19:58, Jacob Shin <jacob.shin@xxxxxxx> wrote: > > On Wed, Jun 26, 2013 at 12:18:27PM +0530, Viresh Kumar wrote: > > >> I am not sure if this is enough. What if we had ondemand as the > >> governor initially, then we changed it to something else. Now also > >> cur_policy contains a address and isn't zero. I just tested this case with this patch applied, and did not have any problems. > >> > >> > cpumask_or(&done, &done, policy->cpus); > >> > + > >> > + if (policy->governor != &cpufreq_gov_ondemand) > >> > + continue; > > > > This should catch that case no ? > > Policy might be freed and reallocated by then. And so doing > policy->governor is dangerous. Are you worried that after we have passed the above if check, and before we access ->tuner governor change might occur? Is there something synonymous to get/put_online_cpus() for cpufreq to prevent governor change while we update ->tuner values? Otherwise, should just spinlock? -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
