Skip to content
Snippets Groups Projects
Select Git revision
  • 3f0a4c873cb341d0cb61493d8dec7662bcaa7ca7
  • openEuler-1.0-LTS default protected
  • openEuler-22.09
  • OLK-5.10
  • openEuler-22.03-LTS
  • openEuler-22.03-LTS-Ascend
  • master
  • openEuler-22.03-LTS-LoongArch-NW
  • openEuler-22.09-HCK
  • openEuler-20.03-LTS-SP3
  • openEuler-21.09
  • openEuler-21.03
  • openEuler-20.09
  • 4.19.90-2210.5.0
  • 5.10.0-123.0.0
  • 5.10.0-60.63.0
  • 5.10.0-60.62.0
  • 4.19.90-2210.4.0
  • 5.10.0-121.0.0
  • 5.10.0-60.61.0
  • 4.19.90-2210.3.0
  • 5.10.0-60.60.0
  • 5.10.0-120.0.0
  • 5.10.0-60.59.0
  • 5.10.0-119.0.0
  • 4.19.90-2210.2.0
  • 4.19.90-2210.1.0
  • 5.10.0-118.0.0
  • 5.10.0-106.19.0
  • 5.10.0-60.58.0
  • 4.19.90-2209.6.0
  • 5.10.0-106.18.0
  • 5.10.0-106.17.0
33 results

arch

  • Clone with SSH
  • Clone with HTTPS
  • user avatar
    Rafael J. Wysocki authored and Linus Torvalds committed
    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 941f5f0f ("x86: CPU: Fix up "cpu MHz"
    in /proc/cpuinfo"), but it was not the reason for the revert and it
    remains applicable.
    
    Fixes: 4815d3c5 (cpufreq: x86: Make scaling_cur_freq behave more as expected)
    Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: default avatarWANG Chao <chao.wang@ucloud.cn>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    b29c6ef7
    History
    Name Last commit Last update
    ..