[PATCH] ppc: cpufreq: Use get_cpu()/put_cpu() instead of smp_processor_id() to avoid the oops

Denis Kirjanov kirjanov at gmail.com
Fri Nov 4 01:56:10 AEDT 2016


On Thursday, November 3, 2016, Gautham R Shenoy <ego at linux.vnet.ibm.com>
wrote:

> Hi Denis,
>
> On Thu, Nov 03, 2016 at 07:20:41AM -0400, Denis Kirjanov wrote:
> > [   67.700897] BUG: using smp_processor_id() in preemptible [00000000]
> code: cat/7343
> > [   67.700988] caller is .powernv_cpufreq_throttle_check+0x2c/0x710
> > [   67.700998] CPU: 13 PID: 7343 Comm: cat Not tainted 4.8.0-rc5-dirty #1
> > [   67.701038] Call Trace:
> > [   67.701066] [c0000007d25b75b0] [c000000000971378]
> .dump_stack+0xe4/0x150 (unreliable)
> > [   67.701153] [c0000007d25b7640] [c0000000005162e4]
> .check_preemption_disabled+0x134/0x150
> > [   67.701238] [c0000007d25b76e0] [c0000000007b63ac]
> .powernv_cpufreq_throttle_check+0x2c/0x710
> > [   67.701322] [c0000007d25b7790] [c0000000007b6d18]
> .powernv_cpufreq_target_index+0x288/0x360
> > [   67.701407] [c0000007d25b7870] [c0000000007acee4]
> .__cpufreq_driver_target+0x394/0x8c0
> > [   67.701491] [c0000007d25b7920] [c0000000007b22ac]
> .cpufreq_set+0x7c/0xd0
> > [   67.701565] [c0000007d25b79b0] [c0000000007adf50]
> .store_scaling_setspeed+0x80/0xc0
> > [   67.701650] [c0000007d25b7a40] [c0000000007ae270] .store+0xa0/0x100
> > [   67.701723] [c0000007d25b7ae0] [c0000000003566e8]
> .sysfs_kf_write+0x88/0xb0
> > [   67.701796] [c0000007d25b7b70] [c0000000003553b8]
> .kernfs_fop_write+0x178/0x260
> > [   67.701881] [c0000007d25b7c10] [c0000000002ac3cc]
> .__vfs_write+0x3c/0x1c0
> > [   67.701954] [c0000007d25b7cf0] [c0000000002ad584]
> .vfs_write+0xc4/0x230
> > [   67.702027] [c0000007d25b7d90] [c0000000002aeef8]
> .SyS_write+0x58/0x100
> > [   67.702101] [c0000007d25b7e30] [c00000000000bfec]
> system_call+0x38/0xfc
> >
> > Signed-off-by: Denis Kirjanov <kda at linux-powerpc.org <javascript:;>>
>
>
> Thanks for looking into this!
> > ---
> >  drivers/cpufreq/powernv-cpufreq.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpufreq/powernv-cpufreq.c
> b/drivers/cpufreq/powernv-cpufreq.c
> > index d3ffde8..4cd91a3 100644
> > --- a/drivers/cpufreq/powernv-cpufreq.c
> > +++ b/drivers/cpufreq/powernv-cpufreq.c
> > @@ -475,7 +475,7 @@ static inline unsigned int get_nominal_index(void)
> >  static void powernv_cpufreq_throttle_check(void *data)
>
> The powernv_cpufreq_throttle_check() checks if the frequency on any of
> the CPUs on this chip has been throttled. Hence it needs to be
> executed without preemption on a CPU on the particular chip.
>
> It is called in two places currently:
>
> a) powernv_cpufreq_work_fn where
> it is called via smp_call_function_any() which will ensure that the
> function will be executed without preempted.
>
> b) from powernv_cpufreq_target_index: Here it should be nested within
> the preempt_disable() preempt_enable() calls. It currently is not.
>
> So, I would suggest fixing b) instead of locally fixing
> smp_processor_id() to get_cpu()/put_cpu().


Ok, I'll send the v2 then.

Thanks!

>
> >  {
> >       struct chip *chip;
> > -     unsigned int cpu = smp_processor_id();
> > +     int cpu;
> >       unsigned long pmsr;
> >       int pmsr_pmax;
> >       unsigned int pmsr_pmax_idx;
> > @@ -491,9 +491,11 @@ static void powernv_cpufreq_throttle_check(void
> *data)
> >                       goto next;
> >               chip->throttled = true;
> >               if (pmsr_pmax_idx > powernv_pstate_info.nominal) {
> > +                     cpu = get_cpu();
> >                       pr_warn_once("CPU %d on Chip %u has Pmax(%d)
> reduced below nominal frequency(%d)\n",
> >                                    cpu, chip->id, pmsr_pmax,
> >                                    idx_to_pstate(powernv_pstate_
> info.nominal));
> > +                     put_cpu();
> >                       chip->throttle_sub_turbo++;
> >               } else {
> >                       chip->throttle_turbo++;
> > --
> > 1.8.3.1
> >
>
> --
> Thanks and Regards
> gautham.
>
>

-- 
Regards / Mit besten Grüßen,
Denis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20161103/eb26bd2d/attachment.html>


More information about the Linuxppc-dev mailing list