[PATCH v4 0/2] cpufreq: acpi-cpufreq: fix P-state index mismatch between perf->states[] and freq_table[]

[PATCH v4 0/2] cpufreq: acpi-cpufreq: fix P-state index mismatch between perf->states[] and freq_table[]

[lirongqing]

From: Li RongQing <lirongqing@baidu.com>

perf->state is an index into perf->states[], but freq_table[] is built by
skipping duplicate _PSS entries, so the two arrays no longer share an index
space. Using perf->state to index freq_table[] therefore reads the wrong
slot. This series fixes the two remaining places that do so.

Changes since v3:
- Reword patch 1 and patch 2 per Zhongqiu Han's review: replace "duplicate
  frequencies" with "entries that are not lower in frequency than the previous
  one" to match the actual dedup condition; expand the extract_io() retry
  description to "sleeps through all 100 iterations - at least ~1 ms of
  usleep_range() plus 100 cross-CPU calls and I/O port reads, all with
  policy->rwsem held"; drop the trailing "through data->resume" from patch 2.
- Add Reviewed-by from Zhongqiu Han.

Changes since v2:
- Reword patch 1;
- Rewrite patch 2, using perf->state to index perf->states[] (its native
  index space) instead of the deduplicated freq_table[]
- Fix the Fixes: tags to point at the actual commits that introduced each

Changes since v1:
- Reword patch 1: v1 described it as an out-of-bounds read, which is wrong;
  it is an index-mismatch / wrong-result bug, not a memory-safety issue.
- Add patch 2 for get_cur_freq_on_cpu().
- Add Fixes: tags (not exact, but reasonable backport targets).

Li RongQing (2):
  cpufreq: acpi-cpufreq: fix P-state index mismatch in extract_io()
  cpufreq: acpi-cpufreq: fix P-state index mismatch in
    get_cur_freq_on_cpu()

 drivers/cpufreq/acpi-cpufreq.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

-- 
2.9.4

[PATCH v4 1/2] cpufreq: acpi-cpufreq: fix P-state index mismatch in extract_io()

[lirongqing]

From: Li RongQing <lirongqing@baidu.com>

When policy->freq_table is built in acpi_cpufreq_cpu_init(), entries
that are not lower in frequency than the previous one are skipped.
For each remaining entry, freq_table[].driver_data stores the
original ACPI P-state index, so the index space of freq_table no
longer matches perf->states[].

extract_io() currently walks perf->states[] with index i and uses the
same i to index policy->freq_table[i]. When duplicate frequencies
exist, this can associate a P-state status with the frequency of a
different P-state. It can also access an invalid or sentinel entry in
freq_table when the number of entries in perf->states[] is greater than
the number of entries remaining in the frequency table.

extract_io() is used on ACPI_ADR_SPACE_SYSTEM_IO platforms by the
frequency verification path, which is enabled by the
acpi_pstate_strict module parameter. With the mismatched lookup,
check_freqs() can fail to match the frequency of the P-state that
drv_write() has already programmed. It then sleeps through all 100
iterations - at least ~1 ms of usleep_range() plus 100 cross-CPU
calls and I/O port reads, all with policy->rwsem held, and
.target_index() returns -EAGAIN, leaving perf->state at its previous
value while the hardware is running at the newly requested P-state.

The cpufreq core consequently keeps policy->cur at the old frequency.
Since __cpufreq_driver_target() returns early when the requested
frequency equals policy->cur, the driver is not called again for that
frequency and the control register is not rewritten. The hardware can
therefore remain at a frequency that differs from the frequency known
to the cpufreq core.

Fix this by iterating over policy->freq_table and using
pos->driver_data as the original ACPI P-state index when accessing
perf->states[], as extract_msr() already does.

Fixes: fe27cb358835 ("[CPUFREQ][2/8] acpi: reorganize code to make MSR support addition easier")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
---
 drivers/cpufreq/acpi-cpufreq.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 10ea603..a797bb2 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -197,14 +197,13 @@ static unsigned extract_io(struct cpufreq_policy *policy, u32 value)
 {
 	struct acpi_cpufreq_data *data = policy->driver_data;
 	struct acpi_processor_performance *perf;
-	int i;
+	struct cpufreq_frequency_table *pos;
 
 	perf = to_perf_data(data);
 
-	for (i = 0; i < perf->state_count; i++) {
-		if (value == perf->states[i].status)
-			return policy->freq_table[i].frequency;
-	}
+	cpufreq_for_each_entry(pos, policy->freq_table)
+		if (value == perf->states[pos->driver_data].status)
+			return pos->frequency;
 	return 0;
 }
 
-- 
2.9.4

[PATCH v4 2/2] cpufreq: acpi-cpufreq: fix P-state index mismatch in get_cur_freq_on_cpu()

[lirongqing]

From: Li RongQing <lirongqing@baidu.com>

get_cur_freq_on_cpu() uses perf->state, which is an index into
perf->states[], to index policy->freq_table[]. However, freq_table[]
is built by filtering _PSS entries that are not lower in frequency
than the previous one, so its index space no longer matches
perf->states[]. The original P-state index for each remaining
freq_table entry is stored in driver_data.

Once an entry has been skipped, using perf->state as an index into
freq_table[] can therefore select the frequency of a different
P-state.

The reported current frequency itself remains correct because it is
obtained from extract_freq(). The mismatch only affects the cached
frequency used by get_cur_freq_on_cpu() to detect a firmware frequency
change behind our back.

If the wrong table entry contains a frequency different from the one
the CPU is actually running at, the check falsely detects a frequency
change and sets data->resume. The next ->target() call then performs a
redundant control-register write even if the requested P-state is
already the current P-state.

Conversely, if the wrong table entry happens to contain the frequency
to which firmware has changed the CPU, the frequency change is missed
and data->resume remains clear. A subsequent ->target() call for the
P-state that the cpufreq core believes to be current can then
short-circuit without rewriting the control register, leaving the CPU
at the firmware-selected frequency until a different P-state is
requested.

Fix this by taking the cached frequency directly from
perf->states[perf->state].core_frequency. perf->state and
perf->states[] use the same P-state index space, and converting
core_frequency to kHz yields the same value stored in the corresponding
freq_table entry during initialization.

Fixes: e56a727b023d ("[CPUFREQ] Make acpi-cpufreq more robust against BIOS freq changes behind our back.")
Reported-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Suggested-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
---
 drivers/cpufreq/acpi-cpufreq.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index a797bb2..3313c74 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -353,6 +353,7 @@ static u32 get_cur_val(const struct cpumask *mask, struct acpi_cpufreq_data *dat
 
 static unsigned int get_cur_freq_on_cpu(unsigned int cpu)
 {
+	struct acpi_processor_performance *perf;
 	struct acpi_cpufreq_data *data;
 	struct cpufreq_policy *policy;
 	unsigned int freq;
@@ -368,7 +369,9 @@ static unsigned int get_cur_freq_on_cpu(unsigned int cpu)
 	if (unlikely(!data || !policy->freq_table))
 		return 0;
 
-	cached_freq = policy->freq_table[to_perf_data(data)->state].frequency;
+	perf = to_perf_data(data);
+	cached_freq = perf->states[perf->state].core_frequency * 1000;
+
 	freq = extract_freq(policy, get_cur_val(cpumask_of(cpu), data));
 	if (freq != cached_freq) {
 		/*
-- 
2.9.4

Re: [PATCH v4 2/2] cpufreq: acpi-cpufreq: fix P-state index mismatch in get_cur_freq_on_cpu()

[Rafael J. Wysocki (Intel)]

On Thu, Sep 10, 2026 at 1:13 PM lirongqing <lirongqing@baidu.com> wrote:
>
> From: Li RongQing <lirongqing@baidu.com>
>
> get_cur_freq_on_cpu() uses perf->state, which is an index into
> perf->states[], to index policy->freq_table[]. However, freq_table[]
> is built by filtering _PSS entries that are not lower in frequency
> than the previous one, so its index space no longer matches
> perf->states[]. The original P-state index for each remaining
> freq_table entry is stored in driver_data.
>
> Once an entry has been skipped, using perf->state as an index into
> freq_table[] can therefore select the frequency of a different
> P-state.
>
> The reported current frequency itself remains correct because it is
> obtained from extract_freq(). The mismatch only affects the cached
> frequency used by get_cur_freq_on_cpu() to detect a firmware frequency
> change behind our back.
>
> If the wrong table entry contains a frequency different from the one
> the CPU is actually running at, the check falsely detects a frequency
> change and sets data->resume. The next ->target() call then performs a
> redundant control-register write even if the requested P-state is
> already the current P-state.
>
> Conversely, if the wrong table entry happens to contain the frequency
> to which firmware has changed the CPU, the frequency change is missed
> and data->resume remains clear. A subsequent ->target() call for the
> P-state that the cpufreq core believes to be current can then
> short-circuit without rewriting the control register, leaving the CPU
> at the firmware-selected frequency until a different P-state is
> requested.
>
> Fix this by taking the cached frequency directly from
> perf->states[perf->state].core_frequency. perf->state and
> perf->states[] use the same P-state index space, and converting
> core_frequency to kHz yields the same value stored in the corresponding
> freq_table entry during initialization.

Sashiko has comments on this patch and it has a point IMV:

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

Can you please tell me what you think?

> Fixes: e56a727b023d ("[CPUFREQ] Make acpi-cpufreq more robust against BIOS freq changes behind our back.")
> Reported-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
> Suggested-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
> ---
>  drivers/cpufreq/acpi-cpufreq.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> index a797bb2..3313c74 100644
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -353,6 +353,7 @@ static u32 get_cur_val(const struct cpumask *mask, struct acpi_cpufreq_data *dat
>
>  static unsigned int get_cur_freq_on_cpu(unsigned int cpu)
>  {
> +       struct acpi_processor_performance *perf;
>         struct acpi_cpufreq_data *data;
>         struct cpufreq_policy *policy;
>         unsigned int freq;
> @@ -368,7 +369,9 @@ static unsigned int get_cur_freq_on_cpu(unsigned int cpu)
>         if (unlikely(!data || !policy->freq_table))
>                 return 0;
>
> -       cached_freq = policy->freq_table[to_perf_data(data)->state].frequency;
> +       perf = to_perf_data(data);
> +       cached_freq = perf->states[perf->state].core_frequency * 1000;
> +
>         freq = extract_freq(policy, get_cur_val(cpumask_of(cpu), data));
>         if (freq != cached_freq) {
>                 /*
> --
> 2.9.4
>

答复: [外部邮件] Re: [PATCH v4 2/2] cpufreq: acpi-cpufreq: fix P-state index mismatch in get_cur_freq_on_cpu()

[Li,Rongqing]

eq: acpi-cpufreq: fix P-state index
> mismatch in get_cur_freq_on_cpu()
> 
> On Thu, Sep 10, 2026 at 1:13 PM lirongqing <lirongqing@baidu.com> wrote:
> >
> > From: Li RongQing <lirongqing@baidu.com>
> >
> > get_cur_freq_on_cpu() uses perf->state, which is an index into
> > perf->states[], to index policy->freq_table[]. However, freq_table[]
> > is built by filtering _PSS entries that are not lower in frequency
> > than the previous one, so its index space no longer matches
> > perf->states[]. The original P-state index for each remaining
> > freq_table entry is stored in driver_data.
> >
> > Once an entry has been skipped, using perf->state as an index into
> > freq_table[] can therefore select the frequency of a different
> > P-state.
> >
> > The reported current frequency itself remains correct because it is
> > obtained from extract_freq(). The mismatch only affects the cached
> > frequency used by get_cur_freq_on_cpu() to detect a firmware frequency
> > change behind our back.
> >
> > If the wrong table entry contains a frequency different from the one
> > the CPU is actually running at, the check falsely detects a frequency
> > change and sets data->resume. The next ->target() call then performs a
> > redundant control-register write even if the requested P-state is
> > already the current P-state.
> >
> > Conversely, if the wrong table entry happens to contain the frequency
> > to which firmware has changed the CPU, the frequency change is missed
> > and data->resume remains clear. A subsequent ->target() call for the
> > P-state that the cpufreq core believes to be current can then
> > short-circuit without rewriting the control register, leaving the CPU
> > at the firmware-selected frequency until a different P-state is
> > requested.
> >
> > Fix this by taking the cached frequency directly from
> > perf->states[perf->state].core_frequency. perf->state and states[] use
> > perf->the same P-state index space, and converting
> > core_frequency to kHz yields the same value stored in the
> > corresponding freq_table entry during initialization.
> 
> Sashiko has comments on this patch and it has a point IMV:
> 
> https://sashiko.dev/#/patchset/20260910111329.2220-1-lirongqing%40baid
> u.com
> 

The extract_msr() fallback issue should be valid , but it is a pre-existing problem that is
orthogonal to the index mismatch fixed by this series. I would therefore prefer to keep this series scoped to that mismatch.

If there is no interest in addressing it here, I will send a separate patch to fix it.

Thanks

[Li,Rongqing] 


> Can you please tell me what you think?
> 
> > Fixes: e56a727b023d ("[CPUFREQ] Make acpi-cpufreq more robust against
> > BIOS freq changes behind our back.")
> > Reported-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
> > Suggested-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
> > Signed-off-by: Li RongQing <lirongqing@baidu.com>
> > Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
> > ---
> >  drivers/cpufreq/acpi-cpufreq.c | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpufreq/acpi-cpufreq.c
> > b/drivers/cpufreq/acpi-cpufreq.c index a797bb2..3313c74 100644
> > --- a/drivers/cpufreq/acpi-cpufreq.c
> > +++ b/drivers/cpufreq/acpi-cpufreq.c
> > @@ -353,6 +353,7 @@ static u32 get_cur_val(const struct cpumask *mask,
> > struct acpi_cpufreq_data *dat
> >
> >  static unsigned int get_cur_freq_on_cpu(unsigned int cpu)  {
> > +       struct acpi_processor_performance *perf;
> >         struct acpi_cpufreq_data *data;
> >         struct cpufreq_policy *policy;
> >         unsigned int freq;
> > @@ -368,7 +369,9 @@ static unsigned int get_cur_freq_on_cpu(unsigned
> int cpu)
> >         if (unlikely(!data || !policy->freq_table))
> >                 return 0;
> >
> > -       cached_freq =
> policy->freq_table[to_perf_data(data)->state].frequency;
> > +       perf = to_perf_data(data);
> > +       cached_freq = perf->states[perf->state].core_frequency * 1000;
> > +
> >         freq = extract_freq(policy, get_cur_val(cpumask_of(cpu), data));
> >         if (freq != cached_freq) {
> >                 /*
> > --
> > 2.9.4
> >