lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20250319100942.578b815d@kf-m2g5>
Date: Wed, 19 Mar 2025 10:09:42 -0500
From: Aaron Rainbolt <arainbolt@...cus.org>
To: srinivas.pandruvada@...ux.intel.com, lenb@...nel.org, rafael@...nel.org,
 viresh.kumar@...aro.org
Cc: linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
 mmikowski@...cus.org
Subject: /sys/devices/system/cpu/cpu* frequency info different between
 kernels 6.8 and 6.11

I haven't looked super closely into this yet (haven't compiled a
mainline kernel and tested it), but it seems that the CPU frequency
info under /sys/devices/system/cpu/cpu* has changed behavior, at least
on Intel CPUs. In particular, the frequencies shown under
/sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq used to show the
maximum CPU frequency the hardware supported, even if turbo boost was
turned off in the intel_pstate driver. (This was the behavior in
kernels 6.8 and prior.) In kernel 6.11 however, they show the maximum
CPU frequency the hardware supports in its current turbo mode, meaning
that if turbo boost is turned off, the maximum CPU frequency shown is
much lower than it is when turbo boost is turned on. This is a bit of a
problem, because some userspace tools (for instance Kubuntu Focus's
Power and Fan tool) depend on cpuinfo_max_freq showing the maximum
frequency of the CPU regardless of turbo boost state, and rely on
base_frequency to show the maximum frequency without turbo boost
enabled. Now in order to read the maximum turbo boost frequency, you
have to at least temporarily enable turbo boost, then read the
frequency info.

To illustrate the issue:

┌─╴aaron@...m2g5:/sys/devices/system/cpu/cpu0/cpufreq
└─╴$ echo '0' | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo > /dev/null
┌─╴aaron@...m2g5:/sys/devices/system/cpu/cpu0/cpufreq
└─╴$ grep . *
affected_cpus:0
base_frequency:2200000
cpuinfo_max_freq:5600000
cpuinfo_min_freq:800000
cpuinfo_transition_latency:20000
energy_performance_available_preferences:default performance balance_performance balance_power power 
energy_performance_preference:balance_performance
related_cpus:0
scaling_available_governors:conservative ondemand userspace powersave performance schedutil 
scaling_cur_freq:1458327
scaling_driver:intel_cpufreq
scaling_governor:ondemand
scaling_max_freq:5600000
scaling_min_freq:800000
scaling_setspeed:<unsupported>
┌─╴aaron@...m2g5:/sys/devices/system/cpu/cpu0/cpufreq
└─╴$ echo '1' | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo > /dev/null
┌─╴aaron@...m2g5:/sys/devices/system/cpu/cpu0/cpufreq
└─╴$ grep . *
affected_cpus:0
base_frequency:2200000
cpuinfo_max_freq:2200000
cpuinfo_min_freq:800000
cpuinfo_transition_latency:20000
energy_performance_available_preferences:default performance balance_performance balance_power power 
energy_performance_preference:balance_performance
related_cpus:0
scaling_available_governors:conservative ondemand userspace powersave performance schedutil 
scaling_cur_freq:917829
scaling_driver:intel_cpufreq
scaling_governor:ondemand
scaling_max_freq:2200000
scaling_min_freq:800000
scaling_setspeed:<unsupported>

This is happening on Ubuntu 24.04 using a 6.11.0-series kernel.

Does this seem like a bug? If so, should I try reproduce it with a
mainline kernel and find the commit that introduced it?

Regards,
Aaron

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ