On Sunday, March 23, 2014 03:09:32 PM Thomas Gleixner wrote: > We are about to free the data structure. Make sure no timer callback > is running. I might be paranoid, but the ->exit callback can be > invoked from so many places, that it is not entirely clear whether > del_timer is always called on the cpu on which it is enqueued. > > While looking through the call sites I noticed, that > cpufreq_init_policy() can fail and invoke cpufreq_driver->exit() but > it does not return the failure and the callsite happily proceeds. > > Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Cc: "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx> > Cc: cpufreq <cpufreq@xxxxxxxxxxxxxxx> > Cc: pm <linux-pm@xxxxxxxxxxxxxxx> Dirk? > --- > > drivers/cpufreq/intel_pstate.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: tip/drivers/cpufreq/intel_pstate.c > =================================================================== > --- tip.orig/drivers/cpufreq/intel_pstate.c > +++ tip/drivers/cpufreq/intel_pstate.c > @@ -777,7 +777,7 @@ static int intel_pstate_cpu_exit(struct > { > int cpu = policy->cpu; > > - del_timer(&all_cpu_data[cpu]->timer); > + del_timer_sync(&all_cpu_data[cpu]->timer); > kfree(all_cpu_data[cpu]); > all_cpu_data[cpu] = NULL; > return 0; > > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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