From: "Li,Rongqing" <lirongqing@baidu.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Sunil V L <sunilvl@ventanamicro.com>,
Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>,
Sudeep Holla <Sudeep.Holla@arm.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
"Huisong Li" <lihuisong@huawei.com>
Subject: 答复: [外部邮件] Re: [PATCH][v2] ACPI: processor_idle: Mark LPI enter functions as __cpuidle
Date: Wed, 24 Jun 2026 01:51:14 +0000 [thread overview]
Message-ID: <731d81865e444be8a9bc07dd121975f3@baidu.com> (raw)
In-Reply-To: <CAJZ5v0j3Wnn3exbji-6PzwjCnOCJDe_pUJU9R25Bhvh1ZE3E5A@mail.gmail.com>
> > 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]
next prev parent reply other threads:[~2026-06-24 1:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 7:26 [PATCH][v2] ACPI: processor_idle: Mark LPI enter functions as __cpuidle lirongqing
2026-06-16 13:12 ` lihuisong (C)
2026-06-23 13:26 ` Rafael J. Wysocki
2026-06-24 1:51 ` Li,Rongqing [this message]
2026-06-24 13:17 ` [外部邮件] " Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=731d81865e444be8a9bc07dd121975f3@baidu.com \
--to=lirongqing@baidu.com \
--cc=Sudeep.Holla@arm.com \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=lihuisong@huawei.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=rafael@kernel.org \
--cc=sunilvl@ventanamicro.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox