kernel/linux.git/drivers/base/cpu.c, branch v4.14.78

x86/speculation/l1tf: Add sysfs reporting for l1tf

2018-08-15T16:12:50+00:00

commit 17dbca119312b4e8173d4e25ff64262119fcef38 upstream L1TF core kernel workarounds are cheap and normally always enabled, However they still should be reported in sysfs if the system is vulnerable or mitigated. Add the necessary CPU feature/bug bits. - Extend the existing checks for Meltdowns to determine if the system is vulnerable. All CPUs which are not vulnerable to Meltdown are also not vulnerable to L1TF - Check for 32bit non PAE and emit a warning as there is no practical way for mitigation due to the limited physical address bits - If the system has more than MAX_PA/2 physical memory the invert page workarounds don't protect the system against the L1TF attack anymore, because an inverted physical address will also point to valid memory. Print a warning in this case and report that the system is vulnerable. Add a function which returns the PFN limit for the L1TF mitigation, which will be used in follow up patches for sanity and range checks. [ tglx: Renamed the CPU feature bit to L1TF_PTEINV ] Signed-off-by: Andi Kleen Signed-off-by: Thomas Gleixner Reviewed-by: Josh Poimboeuf Acked-by: Dave Hansen Signed-off-by: Greg Kroah-Hartman

x86/bugs: Expose /sys/../spec_store_bypass

2018-05-22T16:54:02+00:00

commit c456442cd3a59eeb1d60293c26cbe2ff2c4e42cf upstream Add the sysfs file for the new vulerability. It does not do much except show the words 'Vulnerable' for recent x86 cores. Intel cores prior to family 6 are known not to be vulnerable, and so are some Atoms and some Xeon Phi. It assumes that older Cyrix, Centaur, etc. cores are immune. Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Reviewed-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

sysfs/cpu: Add vulnerability folder

2018-01-17T08:45:27+00:00

commit 87590ce6e373d1a5401f6539f0c59ef92dd924a9 upstream. As the meltdown/spectre problem affects several CPU architectures, it makes sense to have common way to express whether a system is affected by a particular vulnerability or not. If affected the way to express the mitigation should be common as well. Create /sys/devices/system/cpu/vulnerabilities folder and files for meltdown, spectre_v1 and spectre_v2. Allow architectures to override the show function. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Konrad Rzeszutek Wilk Cc: Peter Zijlstra Cc: Will Deacon Cc: Dave Hansen Cc: Linus Torvalds Cc: Borislav Petkov Cc: David Woodhouse Link: https://lkml.kernel.org/r/20180107214913.096657732@linutronix.de Signed-off-by: Greg Kroah-Hartman

Revert "PM / QoS: Fix device resume latency PM QoS"

2017-10-31T17:35:40+00:00

This reverts commit 0cc2b4e5a020 (PM / QoS: Fix device resume latency PM QoS) as it introduced regressions on multiple systems and the fix-up in commit 2a9a86d5c813 (PM / QoS: Fix default runtime_pm device resume latency) does not address all of them. The original problem that commit 0cc2b4e5a020 was attempting to fix will be addressed later. Fixes: 0cc2b4e5a020 (PM / QoS: Fix device resume latency PM QoS) Reported-by: Geert Uytterhoeven Signed-off-by: Rafael J. Wysocki

PM / QoS: Fix device resume latency PM QoS

2017-10-24T13:20:45+00:00

The special value of 0 for device resume latency PM QoS means "no restriction", but there are two problems with that. First, device resume latency PM QoS requests with 0 as the value are always put in front of requests with positive values in the priority lists used internally by the PM QoS framework, causing 0 to be chosen as an effective constraint value. However, that 0 is then interpreted as "no restriction" effectively overriding the other requests with specific restrictions which is incorrect. Second, the users of device resume latency PM QoS have no way to specify that *any* resume latency at all should be avoided, which is an artificial limitation in general. To address these issues, modify device resume latency PM QoS to use S32_MAX as the "no constraint" value and 0 as the "no latency at all" one and rework its users (the cpuidle menu governor, the genpd QoS governor and the runtime PM framework) to follow these changes. Also add a special "n/a" value to the corresponding user space I/F to allow user space to indicate that it cannot accept any resume latencies at all for the given device. Fixes: 85dc0b8a4019 (PM / QoS: Make it possible to expose PM QoS latency constraints) Link: https://bugzilla.kernel.org/show_bug.cgi?id=197323 Reported-by: Reinette Chatre Tested-by: Reinette Chatre Signed-off-by: Rafael J. Wysocki Acked-by: Alex Shi Cc: All applicable

treewide: make "nr_cpu_ids" unsigned

2017-09-09T01:26:48+00:00

First, number of CPUs can't be negative number. Second, different signnnedness leads to suboptimal code in the following cases: 1) kmalloc(nr_cpu_ids * sizeof(X)); "int" has to be sign extended to size_t. 2) while (loff_t *pos < nr_cpu_ids) MOVSXD is 1 byte longed than the same MOV. Other cases exist as well. Basically compiler is told that nr_cpu_ids can't be negative which can't be deduced if it is "int". Code savings on allyesconfig kernel: -3KB add/remove: 0/0 grow/shrink: 25/264 up/down: 261/-3631 (-3370) function old new delta coretemp_cpu_online 450 512 +62 rcu_init_one 1234 1272 +38 pci_device_probe 374 399 +25 ... pgdat_reclaimable_pages 628 556 -72 select_fallback_rq 446 369 -77 task_numa_find_cpu 1923 1807 -116 Link: http://lkml.kernel.org/r/20170819114959.GA30580@avx2 Signed-off-by: Alexey Dobriyan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

CPU / PM: expose pm_qos_resume_latency for CPUs

2017-01-30T10:05:29+00:00

The cpu-dma PM QoS constraint impacts all the cpus in the system. There is no way to let the user to choose a PM QoS constraint per cpu. The following patch exposes to the userspace a per cpu based sysfs file in order to let the userspace to change the value of the PM QoS latency constraint. This change is inoperative in its form and the cpuidle governors have to take into account the per cpu latency constraint in addition to the global cpu-dma latency constraint in order to operate properly. BTW The pm_qos_resume_latency usage defined in Documentation/ABI/testing/sysfs-devices-power The /sys/devices/.../power/pm_qos_resume_latency_us attribute contains the PM QoS resume latency limit for the given device, which is the maximum allowed time it can take to resume the device, after it has been suspended at run time, from a resume request to the moment the device will be ready to process I/O, in microseconds. If it is equal to 0, however, this means that the PM QoS resume latency may be arbitrary. Signed-off-by: Alex Shi Signed-off-by: Rafael J. Wysocki

cpu: clean up register_cpu func

2016-08-31T13:19:55+00:00

This patch could reduce one branch in this function. Also make the code more readble. Signed-off-by: Alex Shi Acked-by: Daniel Lezcano To: linux-kernel@vger.kernel.org To: Greg Kroah-Hartman Cc: linux-pm@vger.kernel.org Cc: Ulf Hansson Cc: Daniel Lezcano Signed-off-by: Greg Kroah-Hartman

drivers/base/cpu.c: use __cpu_*_mask directly

2016-01-21T01:09:18+00:00

The only user of the lvalue-ness of the cpu_*_mask variables is in drivers/base/cpu.c, and that is mostly a work-around for the fact that not even const variables can be used in static initialization. Now that the underlying struct cpumasks are exposed we can take their address. Signed-off-by: Rasmus Villemoes Acked-by: Rusty Russell Acked-by: Greg Kroah-Hartman Cc: Michael Ellerman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

cpu: Remove bogus __ref annotation of cpu_subsys_online()

2015-08-05T22:18:26+00:00

In commit 0db0628d9012 ("kernel: delete __cpuinit usage from all core kernel files") cpu_up() lost its __cpuinit annotation, vanishing the need for cpu_subsys_online() to have a __ref annotation. Just drop it to be able to catch real section mismatches in the future. Signed-off-by: Mathias Krause Cc: Paul Gortmaker Signed-off-by: Greg Kroah-Hartman