diff options
author | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2017-11-13 02:15:39 +0100 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2017-11-13 19:42:39 -0800 |
commit | b29c6ef7bb1257853c1e31616d84f55e561cf631 (patch) | |
tree | dd055a870644df922f4274fdd093b37240268f4f /kernel | |
parent | 99306dfc067e6098365d395168b6fd5db3095292 (diff) | |
download | linux-stable-b29c6ef7bb1257853c1e31616d84f55e561cf631.tar.gz linux-stable-b29c6ef7bb1257853c1e31616d84f55e561cf631.tar.bz2 linux-stable-b29c6ef7bb1257853c1e31616d84f55e561cf631.zip |
x86 / CPU: Avoid unnecessary IPIs in arch_freq_get_on_cpu()
Even though aperfmperf_snapshot_khz() caches the samples.khz value to
return if called again in a sufficiently short time, its caller,
arch_freq_get_on_cpu(), still uses smp_call_function_single() to run it
which may allow user space to trigger an IPI storm by reading from the
scaling_cur_freq cpufreq sysfs file in a tight loop.
To avoid that, move the decision on whether or not to return the cached
samples.khz value to arch_freq_get_on_cpu().
This change was part of commit 941f5f0f6ef5 ("x86: CPU: Fix up "cpu MHz"
in /proc/cpuinfo"), but it was not the reason for the revert and it
remains applicable.
Fixes: 4815d3c56d1e (cpufreq: x86: Make scaling_cur_freq behave more as expected)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: WANG Chao <chao.wang@ucloud.cn>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'kernel')
0 files changed, 0 insertions, 0 deletions