* [patch 15/16] cpufreq: intel-pstate: Use del_timer_sync in intel_pstate_cpu_exit() [not found] <20140323150557.288925975@linutronix.de> @ 2014-03-23 15:09 ` Thomas Gleixner 2014-03-24 1:56 ` Rafael J. Wysocki 2014-03-24 4:45 ` Viresh Kumar 0 siblings, 2 replies; 4+ messages in thread From: Thomas Gleixner @ 2014-03-23 15:09 UTC (permalink / raw) To: LKML; +Cc: Julia Lawall, Andrew Morton, Rafael J. Wysocki, cpufreq, pm [-- Attachment #1: cpufreq-intel-pstate-use-del_timer_sync.patch --] [-- Type: text/plain, Size: 1152 bytes --] 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@linutronix.de> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: cpufreq <cpufreq@vger.kernel.org> Cc: pm <linux-pm@vger.kernel.org> --- 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; ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [patch 15/16] cpufreq: intel-pstate: Use del_timer_sync in intel_pstate_cpu_exit() 2014-03-23 15:09 ` [patch 15/16] cpufreq: intel-pstate: Use del_timer_sync in intel_pstate_cpu_exit() Thomas Gleixner @ 2014-03-24 1:56 ` Rafael J. Wysocki 2014-03-24 14:18 ` Dirk Brandewie 2014-03-24 4:45 ` Viresh Kumar 1 sibling, 1 reply; 4+ messages in thread From: Rafael J. Wysocki @ 2014-03-24 1:56 UTC (permalink / raw) To: Thomas Gleixner, dirk.brandewie, dirk.j.brandewie Cc: LKML, Julia Lawall, Andrew Morton, cpufreq, pm 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@linutronix.de> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> > Cc: cpufreq <cpufreq@vger.kernel.org> > Cc: pm <linux-pm@vger.kernel.org> 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [patch 15/16] cpufreq: intel-pstate: Use del_timer_sync in intel_pstate_cpu_exit() 2014-03-24 1:56 ` Rafael J. Wysocki @ 2014-03-24 14:18 ` Dirk Brandewie 0 siblings, 0 replies; 4+ messages in thread From: Dirk Brandewie @ 2014-03-24 14:18 UTC (permalink / raw) To: Rafael J. Wysocki, Thomas Gleixner, dirk.j.brandewie Cc: dirk.brandewie, LKML, Julia Lawall, Andrew Morton, cpufreq, pm Hi Thomas, On 03/23/2014 06:56 PM, Rafael J. Wysocki wrote: > 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. >> The call to del_timer() has been moved to a new callback in material in Rafaels pull request for v3.15. I will send a patch adding this change to the v3.15 material. --Dirk >> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> >> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> >> Cc: cpufreq <cpufreq@vger.kernel.org> >> Cc: pm <linux-pm@vger.kernel.org> > > 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; >> >> > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [patch 15/16] cpufreq: intel-pstate: Use del_timer_sync in intel_pstate_cpu_exit() 2014-03-23 15:09 ` [patch 15/16] cpufreq: intel-pstate: Use del_timer_sync in intel_pstate_cpu_exit() Thomas Gleixner 2014-03-24 1:56 ` Rafael J. Wysocki @ 2014-03-24 4:45 ` Viresh Kumar 1 sibling, 0 replies; 4+ messages in thread From: Viresh Kumar @ 2014-03-24 4:45 UTC (permalink / raw) To: Thomas Gleixner Cc: LKML, Julia Lawall, Andrew Morton, Rafael J. Wysocki, cpufreq, pm On Sun, Mar 23, 2014 at 8:39 PM, Thomas Gleixner <tglx@linutronix.de> 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. In normal cases it will be called only when CPU goes offline and I hope that isn't called on the dying CPU. > 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. Thanks for reporting this, will get it fixed. > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> > Cc: cpufreq <cpufreq@vger.kernel.org> > Cc: pm <linux-pm@vger.kernel.org> > --- > > 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); Acked-by: Viresh Kumar <viresh.kumar@linaro.org> ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-03-24 14:18 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <20140323150557.288925975@linutronix.de> 2014-03-23 15:09 ` [patch 15/16] cpufreq: intel-pstate: Use del_timer_sync in intel_pstate_cpu_exit() Thomas Gleixner 2014-03-24 1:56 ` Rafael J. Wysocki 2014-03-24 14:18 ` Dirk Brandewie 2014-03-24 4:45 ` Viresh Kumar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).