Re: [PATCH v2 1/4] cpuidle: Skip governor when only one idle state is available

[Guenter Roeck]

On Thu, Mar 05, 2026 at 06:06:53PM +0100, Rafael J. Wysocki wrote:
> On Thu, Mar 5, 2026 at 5:53 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
> >
> > Hi,
> >
> > On Tue, Feb 17, 2026 at 12:20:02AM +0530, Aboorva Devarajan wrote:
> > > On certain platforms (PowerNV systems without a power-mgt DT node),
> > > cpuidle may register only a single idle state. In cases where that
> > > single state is a polling state (state 0), the ladder governor may
> > > incorrectly treat state 1 as the first usable state and pass an
> > > out-of-bounds index. This can lead to a NULL enter callback being
> > > invoked, ultimately resulting in a system crash.
> > >
> > > [   13.342636] cpuidle-powernv : Only Snooze is available
> > > [   13.351854] Faulting instruction address: 0x00000000
> > > [   13.376489] NIP [0000000000000000] 0x0
> > > [   13.378351] LR  [c000000001e01974] cpuidle_enter_state+0x2c4/0x668
> > >
> > > Fix this by adding a bail-out in cpuidle_select() that returns state 0
> > > directly when state_count <= 1, bypassing the governor and keeping the
> > > tick running.
> > >
> > > Fixes: dc2251bf98c6 ("cpuidle: Eliminate the CPUIDLE_DRIVER_STATE_START symbol")
> > > Signed-off-by: Aboorva Devarajan <aboorvad@xxxxxxxxxxxxx>
> > > ---
> > >  drivers/cpuidle/cpuidle.c | 10 ++++++++++
> > >  1 file changed, 10 insertions(+)
> > >
> > > diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> > > index c7876e9e024f..65fbb8e807b9 100644
> > > --- a/drivers/cpuidle/cpuidle.c
> > > +++ b/drivers/cpuidle/cpuidle.c
> > > @@ -359,6 +359,16 @@ noinstr int cpuidle_enter_state(struct cpuidle_device *dev,
> > >  int cpuidle_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
> > >                  bool *stop_tick)
> > >  {
> > > +     /*
> > > +      * If there is only a single idle state (or none), there is nothing
> > > +      * meaningful for the governor to choose. Skip the governor and
> > > +      * always use state 0 with the tick running.
> > > +      */
> > > +     if (drv->state_count <= 1) {
> > > +             *stop_tick = false;
> > > +             return 0;
> > > +     }
> > > +
> >
> > An experimental AI review agent provided the following feedback:
> >
> >  Does this unconditionally keep the tick running on systems that only have a
> >  single non-polling idle state (like basic ARM systems that only support WFI)?
> >
> >  Before this patch, governors like menu would check CPUIDLE_FLAG_POLLING before
> >  deciding to keep the tick running. Could this change effectively disable
> >  NO_HZ_IDLE on these systems, causing higher power consumption?
> >
> > I don't know scheduling well enough to understand if this is a real problem,
> > but I thought it is worth mentioning it.
> >
> > Please let me know if the problem is real or not so I can feed it back into
> > the agent.
> 
> On bare metal, this isn't a problem at least in practice because the
> only available idle state cannot be too deep anyway, so stopping the
> tick doesn't improve energy efficiency too much and it adds overhead.
> 
> On virt, it may be a problem if the tick that runs in the VM
> effectively prevents the host from using deep idle states, but that
> would only matter for VMs running on systems that have deep enough
> idle state in configurations where the VM has only one idle state.
> 
> This is kind of under discussion in a separate thread here:
> https://lore.kernel.org/lkml/20260301192915.171574741@xxxxxxxxxx/#r

Thanks a lot for the feedback!

Guenter