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@xxxxxxxxx> wrote:
>
> From: Li RongQing <lirongqing@xxxxxxxxx>
>
> 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@xxxxxxxxx>
> ---
> 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.