[PATCH v2 0/4] cpuidle: Fix crash with single idle state

[PATCH v2 0/4] cpuidle: Fix crash with single idle state

[Aboorva Devarajan]

When a cpuidle driver registers only a single idle state, the ladder
governor can compute an out-of-bounds index, leading to a NULL pointer
dereference in cpuidle_enter_state().

Patch 1 fixes this by adding a bail-out in cpuidle_select() that
bypasses the governor entirely when state_count <= 1.

Patches 2-4 remove the now-redundant single-state handling from the
haltpoll, teo, and menu governors.

v1:
https://lore.kernel.org/all/20260211053552.739337-1-aboorvad@linux.ibm.com/

v1 -> v2:
- Move fix to cpuidle_select() core bail-out instead of ladder governor
- Remove redundant single-state handling from menu, teo, haltpoll

Aboorva Devarajan (2):
  cpuidle: Skip governor when only one idle state is available
  cpuidle: haltpoll: Remove single state handling

Christian Loehle (2):
  cpuidle: teo: Remove single state handling
  cpuidle: menu: Remove single state handling

 drivers/cpuidle/cpuidle.c            | 10 ++++++++++
 drivers/cpuidle/governors/haltpoll.c |  2 +-
 drivers/cpuidle/governors/menu.c     |  2 +-
 drivers/cpuidle/governors/teo.c      |  6 ------
 4 files changed, 12 insertions(+), 8 deletions(-)

-- 
2.52.0

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

[Aboorva Devarajan]

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@linux.ibm.com>
---
 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;
+	}
+
 	return cpuidle_curr_governor->select(drv, dev, stop_tick);
 }
 
-- 
2.52.0

[PATCH v2 2/4] cpuidle: haltpoll: Remove single state handling

[Aboorva Devarajan]

cpuidle systems where the governor has no choice because there's only
a single idle state are now handled by cpuidle core and bypass the
governor, so remove the related handling.

Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
---
 drivers/cpuidle/governors/haltpoll.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpuidle/governors/haltpoll.c b/drivers/cpuidle/governors/haltpoll.c
index 663b7f164d20..ed3952df8526 100644
--- a/drivers/cpuidle/governors/haltpoll.c
+++ b/drivers/cpuidle/governors/haltpoll.c
@@ -52,7 +52,7 @@ static int haltpoll_select(struct cpuidle_driver *drv,
 {
 	s64 latency_req = cpuidle_governor_latency_req(dev->cpu);
 
-	if (!drv->state_count || latency_req == 0) {
+	if (latency_req == 0) {
 		*stop_tick = false;
 		return 0;
 	}
-- 
2.52.0

[PATCH v2 3/4] cpuidle: teo: Remove single state handling

[Aboorva Devarajan]

From: Christian Loehle <christian.loehle@arm.com>

cpuidle systems where the governor has no choice because there's only
a single idle state are now handled by cpuidle core and bypass the
governor, so remove the related handling.

Signed-off-by: Christian Loehle <christian.loehle@arm.com>
---
 drivers/cpuidle/governors/teo.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/drivers/cpuidle/governors/teo.c b/drivers/cpuidle/governors/teo.c
index 81ac5fd58a1c..9b5b8c617806 100644
--- a/drivers/cpuidle/governors/teo.c
+++ b/drivers/cpuidle/governors/teo.c
@@ -317,12 +317,6 @@ static int teo_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
 	 */
 	cpu_data->sleep_length_ns = KTIME_MAX;
 
-	/* Check if there is any choice in the first place. */
-	if (drv->state_count < 2) {
-		idx = 0;
-		goto out_tick;
-	}
-
 	if (!dev->states_usage[0].disable)
 		idx = 0;
 
-- 
2.52.0

[PATCH v2 4/4] cpuidle: menu: Remove single state handling

[Aboorva Devarajan]

From: Christian Loehle <christian.loehle@arm.com>

cpuidle systems where the governor has no choice because there's only
a single idle state are now handled by cpuidle core and bypass the
governor, so remove the related handling.

Signed-off-by: Christian Loehle <christian.loehle@arm.com>
---
 drivers/cpuidle/governors/menu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index 64d6f7a1c776..fdfa5d7e10a6 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -271,7 +271,7 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
 		data->bucket = BUCKETS - 1;
 	}
 
-	if (unlikely(drv->state_count <= 1 || latency_req == 0) ||
+	if (unlikely(latency_req == 0) ||
 	    ((data->next_timer_ns < drv->states[1].target_residency_ns ||
 	      latency_req < drv->states[1].exit_latency_ns) &&
 	     !dev->states_usage[0].disable)) {
-- 
2.52.0

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

[Christian Loehle]

On 2/16/26 18:50, 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@linux.ibm.com>

Reviewed-by: Christian Loehle <christian.loehle@arm.com>

> ---
>  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;
> +	}
> +
>  	return cpuidle_curr_governor->select(drv, dev, stop_tick);
>  }
>  

Re: [PATCH v2 2/4] cpuidle: haltpoll: Remove single state handling

[Christian Loehle]

On 2/16/26 18:50, Aboorva Devarajan wrote:
> cpuidle systems where the governor has no choice because there's only
> a single idle state are now handled by cpuidle core and bypass the
> governor, so remove the related handling.
> 
> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>

Good catch, thanks!
Reviewed-by: Christian Loehle <christian.loehle@arm.com>

> ---
>  drivers/cpuidle/governors/haltpoll.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpuidle/governors/haltpoll.c b/drivers/cpuidle/governors/haltpoll.c
> index 663b7f164d20..ed3952df8526 100644
> --- a/drivers/cpuidle/governors/haltpoll.c
> +++ b/drivers/cpuidle/governors/haltpoll.c
> @@ -52,7 +52,7 @@ static int haltpoll_select(struct cpuidle_driver *drv,
>  {
>  	s64 latency_req = cpuidle_governor_latency_req(dev->cpu);
>  
> -	if (!drv->state_count || latency_req == 0) {
> +	if (latency_req == 0) {
>  		*stop_tick = false;
>  		return 0;
>  	}

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

[Rafael J. Wysocki]

On Tue, Feb 17, 2026 at 3:36 PM Christian Loehle
<christian.loehle@arm.com> wrote:
>
> On 2/16/26 18:50, 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@linux.ibm.com>
>
> Reviewed-by: Christian Loehle <christian.loehle@arm.com>
>
> > ---
> >  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;
> > +     }
> > +
> >       return cpuidle_curr_governor->select(drv, dev, stop_tick);
> >  }
> >

I've queued up the series for 7.0-rc1 because it is mostly
straightforward, but I've modified the second patch to drop the
redundant latency_req variable and I had to rebase the last one.

Thanks!

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

[Guenter Roeck]

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@linux.ibm.com>
> ---
>  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.

Thanks,
Guenter

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

[Rafael J. Wysocki]

On Thu, Mar 5, 2026 at 5:53 PM Guenter Roeck <linux@roeck-us.net> 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@linux.ibm.com>
> > ---
> >  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@kernel.org/#r

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@roeck-us.net> 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@linux.ibm.com>
> > > ---
> > >  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@kernel.org/#r

Thanks a lot for the feedback!

Guenter