[PATCH v1] cpufreq: Return current frequency when frequency table is unavailable

[PATCH v1] cpufreq: Return current frequency when frequency table is unavailable

[Zihuan Zhang]

In cases where the CPU frequency table (freq_table) is not available,
the __resolve_freq() function will now return the current frequency
(policy->cur) instead of the requested target frequency. This ensures
that the system doesn't return an invalid or uninitialized frequency
value when frequency scaling is not supported or not initialized.

This change improves the stability of the frequency scaling logic when
the CPU frequency table is not populated, preventing errors related
to unavailable frequency tables.

Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn>
---
 drivers/cpufreq/cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index fc7eace8b65b..ca9b7807a288 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -502,7 +502,7 @@ static unsigned int __resolve_freq(struct cpufreq_policy *policy,
 	target_freq = clamp_val(target_freq, min, max);
 
 	if (!policy->freq_table)
-		return target_freq;
+		return policy->cur;
 
 	idx = cpufreq_frequency_table_target(policy, target_freq, min, max, relation);
 	policy->cached_resolved_idx = idx;
-- 
2.25.1

Re: [PATCH v1] cpufreq: Return current frequency when frequency table is unavailable

[Viresh Kumar]

On 14-08-25, 16:52, Zihuan Zhang wrote:
> In cases where the CPU frequency table (freq_table) is not available,
> the __resolve_freq() function will now return the current frequency
> (policy->cur) instead of the requested target frequency. This ensures
> that the system doesn't return an invalid or uninitialized frequency
> value when frequency scaling is not supported or not initialized.
> 
> This change improves the stability of the frequency scaling logic when
> the CPU frequency table is not populated, preventing errors related
> to unavailable frequency tables.

Is there a real problem you are facing ? Or a code that path can do
some harm ? I think this patch may end up breaking users.

-- 
viresh

Re: [PATCH v1] cpufreq: Return current frequency when frequency table is unavailable

[Zihuan Zhang]

在 2025/8/14 17:02, Viresh Kumar 写道:
> On 14-08-25, 16:52, Zihuan Zhang wrote:
>> In cases where the CPU frequency table (freq_table) is not available,
>> the __resolve_freq() function will now return the current frequency
>> (policy->cur) instead of the requested target frequency. This ensures
>> that the system doesn't return an invalid or uninitialized frequency
>> value when frequency scaling is not supported or not initialized.
>>
>> This change improves the stability of the frequency scaling logic when
>> the CPU frequency table is not populated, preventing errors related
>> to unavailable frequency tables.
> Is there a real problem you are facing ? Or a code that path can do
> some harm ? I think this patch may end up breaking users.

Haven’t yet.

I just feel that it might not be ideal to set a frequency when the 
frequency table is unavailable.

Perhaps adding a log or warning when the frequency table is missing 
could be a better approach.

Re: [PATCH v1] cpufreq: Return current frequency when frequency table is unavailable

[Viresh Kumar]

On 14-08-25, 17:24, Zihuan Zhang wrote:
> I just feel that it might not be ideal to set a frequency when the frequency
> table is unavailable.
> 
> Perhaps adding a log or warning when the frequency table is missing could be
> a better approach.

There are a lot of drivers that don't provide a frequency table, i.e.
drivers with setpolicy() or target() callbacks. Only the
target_index() ones provide a freq table.

-- 
viresh

Re: [PATCH v1] cpufreq: Return current frequency when frequency table is unavailable

[Zihuan Zhang]

在 2025/8/14 17:31, Viresh Kumar 写道:
> On 14-08-25, 17:24, Zihuan Zhang wrote:
>> I just feel that it might not be ideal to set a frequency when the frequency
>> table is unavailable.
>>
>> Perhaps adding a log or warning when the frequency table is missing could be
>> a better approach.
> There are a lot of drivers that don't provide a frequency table, i.e.
> drivers with setpolicy() or target() callbacks. Only the
> target_index() ones provide a freq table.
>
Thank you for the explanation! I now understand that some drivers do not 
require a frequency table to set the frequency.

I will drop it.

Best regards,
Zihuan Zhang

Re: [PATCH v1] cpufreq: Return current frequency when frequency table is unavailable

[kernel test robot]

Hello,

kernel test robot noticed "xfstests.xfs.177.fail" on:

commit: 69f6747d99d0b1482fb38c36dfa26fe22654ff1f ("[PATCH v1] cpufreq: Return current frequency when frequency table is unavailable")
url: https://github.com/intel-lab-lkp/linux/commits/Zihuan-Zhang/cpufreq-Return-current-frequency-when-frequency-table-is-unavailable/20250814-165519
base: https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git linux-next
patch link: https://lore.kernel.org/all/20250814085216.358207-1-zhangzihuan@kylinos.cn/
patch subject: [PATCH v1] cpufreq: Return current frequency when frequency table is unavailable

in testcase: xfstests
version: xfstests-x86_64-e1e4a0ea-1_20250714
with following parameters:

	disk: 4HDD
	fs: xfs
	test: xfs-177


config: x86_64-rhel-9.4-func
compiler: gcc-12
test machine: 4 threads Intel(R) Xeon(R) CPU E3-1225 v5 @ 3.30GHz (Skylake) with 16G memory

(please refer to attached dmesg/kmsg for entire log/backtrace)


If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202508180834.3b8fe9d6-lkp@intel.com

2025-08-16 15:56:36 export TEST_DIR=/fs/sda1
2025-08-16 15:56:36 export TEST_DEV=/dev/sda1
2025-08-16 15:56:36 export FSTYP=xfs
2025-08-16 15:56:36 export SCRATCH_MNT=/fs/scratch
2025-08-16 15:56:36 mkdir /fs/scratch -p
2025-08-16 15:56:36 export SCRATCH_DEV=/dev/sda4
2025-08-16 15:56:36 export SCRATCH_LOGDEV=/dev/sda2
2025-08-16 15:56:36 export SCRATCH_XFS_LIST_METADATA_FIELDS=u3.sfdir3.hdr.parent.i4
2025-08-16 15:56:36 export SCRATCH_XFS_LIST_FUZZ_VERBS=random
2025-08-16 15:56:36 echo xfs/177
2025-08-16 15:56:36 ./check xfs/177
FSTYP         -- xfs (non-debug)
PLATFORM      -- Linux/x86_64 lkp-skl-d06 6.17.0-rc1-00011-g69f6747d99d0 #1 SMP PREEMPT_DYNAMIC Sat Aug 16 23:40:03 CST 2025
MKFS_OPTIONS  -- -f /dev/sda4
MOUNT_OPTIONS -- /dev/sda4 /fs/scratch

xfs/177       - output mismatch (see /lkp/benchmarks/xfstests/results//xfs/177.out.bad)
    --- tests/xfs/177.out	2025-07-14 17:48:52.000000000 +0000
    +++ /lkp/benchmarks/xfstests/results//xfs/177.out.bad	2025-08-16 15:57:27.495121515 +0000
    @@ -2,11 +2,14 @@
     new file count is in range
     inodes after creating files is in range
     Round 1
    -inodes after bulkstat is in range
    +inodes after bulkstat has value of 4
    +inodes after bulkstat is NOT in range 1023 .. 1033
     inodes after expire is in range
    ...
    (Run 'diff -u /lkp/benchmarks/xfstests/tests/xfs/177.out /lkp/benchmarks/xfstests/results//xfs/177.out.bad'  to see the entire diff)

HINT: You _MAY_ be missing kernel fix:
      f38a032b165d xfs: fix I_DONTCACHE

Ran: xfs/177
Failures: xfs/177
Failed 1 of 1 tests




The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20250818/202508180834.3b8fe9d6-lkp@intel.com



-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki