[PATCH][v2] ACPI: processor_idle: Mark LPI enter functions as __cpuidle

[PATCH][v2] ACPI: processor_idle: Mark LPI enter functions as __cpuidle

[lirongqing]

From: Li RongQing <lirongqing@baidu.com>

When function tracing or Kprobes is enabled, entering an ACPI Low
Power Idle (LPI) state triggers the following RCU splat:

  RCU not on for: acpi_idle_lpi_enter+0x4/0xd8
  WARNING: CPU: 8 PID: 0 at include/linux/trace_recursion.h:162 function_trace_call+0x1e8/0x228

The acpi_idle_lpi_enter() function is invoked within the cpuidle
path after RCU has already been disabled for the current local CPU.
Consequently, ftrace's function_trace_call() expects RCU to be
actively watching before recording trace data, emitting a warning
if it is not.

Fix this by annotating acpi_idle_lpi_enter(), the generic __weak
stub, and the RISC-V implementation of acpi_processor_ffh_lpi_enter()
with __cpuidle. This moves these functions into the '.cpuidle.text'
section, implicitly disabling ftrace instrumentation (notrace) along
this sensitive path and preventing trace-induced RCU warnings during
idle entry.

Fixes: a36a7fecfe60 ("ACPI / processor_idle: Add support for Low Power Idle(LPI) states")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
Diff with v1: add __cpuidle to acpi_processor_ffh_lpi_enter

 drivers/acpi/processor_idle.c | 4 ++--
 drivers/acpi/riscv/cpuidle.c  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 390ab5f..4482cf2 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -1143,7 +1143,7 @@ static int acpi_processor_get_lpi_info(struct acpi_processor *pr)
 	return 0;
 }
 
-int __weak acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
+int __weak __cpuidle acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
 {
 	return -ENODEV;
 }
@@ -1156,7 +1156,7 @@ int __weak acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
  *
  * Return: 0 for success or negative value for error
  */
-static int acpi_idle_lpi_enter(struct cpuidle_device *dev,
+static int __cpuidle acpi_idle_lpi_enter(struct cpuidle_device *dev,
 			       struct cpuidle_driver *drv, int index)
 {
 	struct acpi_processor *pr;
diff --git a/drivers/acpi/riscv/cpuidle.c b/drivers/acpi/riscv/cpuidle.c
index 624f9bb..c76dbab 100644
--- a/drivers/acpi/riscv/cpuidle.c
+++ b/drivers/acpi/riscv/cpuidle.c
@@ -66,7 +66,7 @@ int acpi_processor_ffh_lpi_probe(unsigned int cpu)
 	return acpi_cpu_init_idle(cpu);
 }
 
-int acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
+int __cpuidle acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
 {
 	u32 state = lpi->address;
 
-- 
2.9.4

Re: [PATCH][v2] ACPI: processor_idle: Mark LPI enter functions as __cpuidle

[lihuisong (C)]

On 6/16/2026 3:26 PM, lirongqing wrote:
> From: Li RongQing <lirongqing@baidu.com>
>
> When function tracing or Kprobes is enabled, entering an ACPI Low
> Power Idle (LPI) state triggers the following RCU splat:
>
>    RCU not on for: acpi_idle_lpi_enter+0x4/0xd8
>    WARNING: CPU: 8 PID: 0 at include/linux/trace_recursion.h:162 function_trace_call+0x1e8/0x228
>
> The acpi_idle_lpi_enter() function is invoked within the cpuidle
> path after RCU has already been disabled for the current local CPU.
> Consequently, ftrace's function_trace_call() expects RCU to be
> actively watching before recording trace data, emitting a warning
> if it is not.
>
> Fix this by annotating acpi_idle_lpi_enter(), the generic __weak
> stub, and the RISC-V implementation of acpi_processor_ffh_lpi_enter()
> with __cpuidle. This moves these functions into the '.cpuidle.text'
> section, implicitly disabling ftrace instrumentation (notrace) along
> this sensitive path and preventing trace-induced RCU warnings during
> idle entry.
>
> Fixes: a36a7fecfe60 ("ACPI / processor_idle: Add support for Low Power Idle(LPI) states")
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
LGTM,
Acked-by: lihuisong@huawei.com

Re: [PATCH][v2] ACPI: processor_idle: Mark LPI enter functions as __cpuidle

[Rafael J. Wysocki]

On Tue, Jun 16, 2026 at 9:26 AM lirongqing <lirongqing@baidu.com> wrote:
>
> From: Li RongQing <lirongqing@baidu.com>
>
> When function tracing or Kprobes is enabled, entering an ACPI Low
> Power Idle (LPI) state triggers the following RCU splat:
>
>   RCU not on for: acpi_idle_lpi_enter+0x4/0xd8
>   WARNING: CPU: 8 PID: 0 at include/linux/trace_recursion.h:162 function_trace_call+0x1e8/0x228
>
> The acpi_idle_lpi_enter() function is invoked within the cpuidle
> path after RCU has already been disabled for the current local CPU.
> Consequently, ftrace's function_trace_call() expects RCU to be
> actively watching before recording trace data, emitting a warning
> if it is not.
>
> Fix this by annotating acpi_idle_lpi_enter(), the generic __weak
> stub, and the RISC-V implementation of acpi_processor_ffh_lpi_enter()
> with __cpuidle. This moves these functions into the '.cpuidle.text'
> section, implicitly disabling ftrace instrumentation (notrace) along
> this sensitive path and preventing trace-induced RCU warnings during
> idle entry.
>
> Fixes: a36a7fecfe60 ("ACPI / processor_idle: Add support for Low Power Idle(LPI) states")
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
> Diff with v1: add __cpuidle to acpi_processor_ffh_lpi_enter
>
>  drivers/acpi/processor_idle.c | 4 ++--
>  drivers/acpi/riscv/cpuidle.c  | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
> index 390ab5f..4482cf2 100644
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -1143,7 +1143,7 @@ static int acpi_processor_get_lpi_info(struct acpi_processor *pr)
>         return 0;
>  }
>
> -int __weak acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
> +int __weak __cpuidle acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
>  {
>         return -ENODEV;
>  }
> @@ -1156,7 +1156,7 @@ int __weak acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
>   *
>   * Return: 0 for success or negative value for error
>   */
> -static int acpi_idle_lpi_enter(struct cpuidle_device *dev,
> +static int __cpuidle acpi_idle_lpi_enter(struct cpuidle_device *dev,
>                                struct cpuidle_driver *drv, int index)
>  {
>         struct acpi_processor *pr;
> diff --git a/drivers/acpi/riscv/cpuidle.c b/drivers/acpi/riscv/cpuidle.c
> index 624f9bb..c76dbab 100644
> --- a/drivers/acpi/riscv/cpuidle.c
> +++ b/drivers/acpi/riscv/cpuidle.c
> @@ -66,7 +66,7 @@ int acpi_processor_ffh_lpi_probe(unsigned int cpu)
>         return acpi_cpu_init_idle(cpu);
>  }
>
> -int acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
> +int __cpuidle acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
>  {
>         u32 state = lpi->address;
>
> --

Sashiko says that this change may not be sufficient to fully address the issue

https://sashiko.dev/#/patchset/20260616072617.2272-1-lirongqing%40baidu.com

and that appears to be a valid concern.

答复: [外部邮件] Re: [PATCH][v2] ACPI: processor_idle: Mark LPI enter functions as __cpuidle

[Li,Rongqing]

> > The acpi_idle_lpi_enter() function is invoked within the cpuidle path
> > after RCU has already been disabled for the current local CPU.
> > Consequently, ftrace's function_trace_call() expects RCU to be
> > actively watching before recording trace data, emitting a warning if
> > it is not.
> >
> > Fix this by annotating acpi_idle_lpi_enter(), the generic __weak stub,
> > and the RISC-V implementation of acpi_processor_ffh_lpi_enter() with
> > __cpuidle. This moves these functions into the '.cpuidle.text'
> > section, implicitly disabling ftrace instrumentation (notrace) along
> > this sensitive path and preventing trace-induced RCU warnings during
> > idle entry.
> >
> > Fixes: a36a7fecfe60 ("ACPI / processor_idle: Add support for Low Power
> > Idle(LPI) states")
> > Signed-off-by: Li RongQing <lirongqing@baidu.com>
> > ---
> > Diff with v1: add __cpuidle to acpi_processor_ffh_lpi_enter
> >
> >  drivers/acpi/processor_idle.c | 4 ++--  drivers/acpi/riscv/cpuidle.c
> > | 2 +-
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/acpi/processor_idle.c
> > b/drivers/acpi/processor_idle.c index 390ab5f..4482cf2 100644
> > --- a/drivers/acpi/processor_idle.c
> > +++ b/drivers/acpi/processor_idle.c
> > @@ -1143,7 +1143,7 @@ static int acpi_processor_get_lpi_info(struct
> acpi_processor *pr)
> >         return 0;
> >  }
> >
> > -int __weak acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
> > +int __weak __cpuidle acpi_processor_ffh_lpi_enter(struct
> > +acpi_lpi_state *lpi)
> >  {
> >         return -ENODEV;
> >  }
> > @@ -1156,7 +1156,7 @@ int __weak acpi_processor_ffh_lpi_enter(struct
> acpi_lpi_state *lpi)
> >   *
> >   * Return: 0 for success or negative value for error
> >   */
> > -static int acpi_idle_lpi_enter(struct cpuidle_device *dev,
> > +static int __cpuidle acpi_idle_lpi_enter(struct cpuidle_device *dev,
> >                                struct cpuidle_driver *drv, int index)
> > {
> >         struct acpi_processor *pr;
> > diff --git a/drivers/acpi/riscv/cpuidle.c
> > b/drivers/acpi/riscv/cpuidle.c index 624f9bb..c76dbab 100644
> > --- a/drivers/acpi/riscv/cpuidle.c
> > +++ b/drivers/acpi/riscv/cpuidle.c
> > @@ -66,7 +66,7 @@ int acpi_processor_ffh_lpi_probe(unsigned int cpu)
> >         return acpi_cpu_init_idle(cpu);  }
> >
> > -int acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
> > +int __cpuidle acpi_processor_ffh_lpi_enter(struct acpi_lpi_state
> > +*lpi)
> >  {
> >         u32 state = lpi->address;
> >
> > --
> 
> Sashiko says that this change may not be sufficient to fully address the issue
> 
> https://sashiko.dev/#/patchset/20260616072617.2272-1-lirongqing%40baidu
> .com
> 
> and that appears to be a valid concern.

Should this fix be placed in a separate patch? CPU_PM_CPU_IDLE_ENTER_PARAM is also invoked by sbi_cpuidle_enter_state, which is itself already annotated with __cpuidle, so this appears to be a pre-existing issue in the RISC-V tree. It would be more appropriate to have RISC-V experts to fix it independently.

Thanks

[Li,Rongqing] 

Re: [外部邮件] Re: [PATCH][v2] ACPI: processor_idle: Mark LPI enter functions as __cpuidle

[Rafael J. Wysocki]

On Wed, Jun 24, 2026 at 3:51 AM Li,Rongqing <lirongqing@baidu.com> wrote:
>
> > > The acpi_idle_lpi_enter() function is invoked within the cpuidle path
> > > after RCU has already been disabled for the current local CPU.
> > > Consequently, ftrace's function_trace_call() expects RCU to be
> > > actively watching before recording trace data, emitting a warning if
> > > it is not.
> > >
> > > Fix this by annotating acpi_idle_lpi_enter(), the generic __weak stub,
> > > and the RISC-V implementation of acpi_processor_ffh_lpi_enter() with
> > > __cpuidle. This moves these functions into the '.cpuidle.text'
> > > section, implicitly disabling ftrace instrumentation (notrace) along
> > > this sensitive path and preventing trace-induced RCU warnings during
> > > idle entry.
> > >
> > > Fixes: a36a7fecfe60 ("ACPI / processor_idle: Add support for Low Power
> > > Idle(LPI) states")
> > > Signed-off-by: Li RongQing <lirongqing@baidu.com>
> > > ---
> > > Diff with v1: add __cpuidle to acpi_processor_ffh_lpi_enter
> > >
> > >  drivers/acpi/processor_idle.c | 4 ++--  drivers/acpi/riscv/cpuidle.c
> > > | 2 +-
> > >  2 files changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/acpi/processor_idle.c
> > > b/drivers/acpi/processor_idle.c index 390ab5f..4482cf2 100644
> > > --- a/drivers/acpi/processor_idle.c
> > > +++ b/drivers/acpi/processor_idle.c
> > > @@ -1143,7 +1143,7 @@ static int acpi_processor_get_lpi_info(struct
> > acpi_processor *pr)
> > >         return 0;
> > >  }
> > >
> > > -int __weak acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
> > > +int __weak __cpuidle acpi_processor_ffh_lpi_enter(struct
> > > +acpi_lpi_state *lpi)
> > >  {
> > >         return -ENODEV;
> > >  }
> > > @@ -1156,7 +1156,7 @@ int __weak acpi_processor_ffh_lpi_enter(struct
> > acpi_lpi_state *lpi)
> > >   *
> > >   * Return: 0 for success or negative value for error
> > >   */
> > > -static int acpi_idle_lpi_enter(struct cpuidle_device *dev,
> > > +static int __cpuidle acpi_idle_lpi_enter(struct cpuidle_device *dev,
> > >                                struct cpuidle_driver *drv, int index)
> > > {
> > >         struct acpi_processor *pr;
> > > diff --git a/drivers/acpi/riscv/cpuidle.c
> > > b/drivers/acpi/riscv/cpuidle.c index 624f9bb..c76dbab 100644
> > > --- a/drivers/acpi/riscv/cpuidle.c
> > > +++ b/drivers/acpi/riscv/cpuidle.c
> > > @@ -66,7 +66,7 @@ int acpi_processor_ffh_lpi_probe(unsigned int cpu)
> > >         return acpi_cpu_init_idle(cpu);  }
> > >
> > > -int acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
> > > +int __cpuidle acpi_processor_ffh_lpi_enter(struct acpi_lpi_state
> > > +*lpi)
> > >  {
> > >         u32 state = lpi->address;
> > >
> > > --
> >
> > Sashiko says that this change may not be sufficient to fully address the issue
> >
> > https://sashiko.dev/#/patchset/20260616072617.2272-1-lirongqing%40baidu
> > .com
> >
> > and that appears to be a valid concern.
>
> Should this fix be placed in a separate patch? CPU_PM_CPU_IDLE_ENTER_PARAM
> is also invoked by sbi_cpuidle_enter_state, which is itself already annotated with __cpuidle,
> so this appears to be a pre-existing issue in the RISC-V tree. It would be more appropriate
> to have RISC-V experts to fix it independently.

OK, fair enough.

Applied as 7.2-rc material, thanks!