aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2020-11-19Merge branches 'cpuinfo.2020.11.06a', 'doc.2020.11.06a', 'fixes.2020.11.19b', 'lockdep.2020.11.02a', 'tasks.2020.11.06a' and 'torture.2020.11.06a' into HEADPaul E. McKenney2-2/+1
cpuinfo.2020.11.06a: Speedups for /proc/cpuinfo. doc.2020.11.06a: Documentation updates. fixes.2020.11.19b: Miscellaneous fixes. lockdep.2020.11.02a: Lockdep-RCU updates to avoid "unused variable". tasks.2020.11.06a: Tasks-RCU updates. torture.2020.11.06a': Torture-test updates.
2020-11-19x86/smpboot: Move rcu_cpu_starting() earlierPaul E. McKenney2-2/+1
The call to rcu_cpu_starting() in mtrr_ap_init() is not early enough in the CPU-hotplug onlining process, which results in lockdep splats as follows: ============================= WARNING: suspicious RCU usage 5.9.0+ #268 Not tainted ----------------------------- kernel/kprobes.c:300 RCU-list traversed in non-reader section!! other info that might help us debug this: RCU used illegally from offline CPU! rcu_scheduler_active = 1, debug_locks = 1 no locks held by swapper/1/0. stack backtrace: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.9.0+ #268 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace: dump_stack+0x77/0x97 __is_insn_slot_addr+0x15d/0x170 kernel_text_address+0xba/0xe0 ? get_stack_info+0x22/0xa0 __kernel_text_address+0x9/0x30 show_trace_log_lvl+0x17d/0x380 ? dump_stack+0x77/0x97 dump_stack+0x77/0x97 __lock_acquire+0xdf7/0x1bf0 lock_acquire+0x258/0x3d0 ? vprintk_emit+0x6d/0x2c0 _raw_spin_lock+0x27/0x40 ? vprintk_emit+0x6d/0x2c0 vprintk_emit+0x6d/0x2c0 printk+0x4d/0x69 start_secondary+0x1c/0x100 secondary_startup_64_no_verify+0xb8/0xbb This is avoided by moving the call to rcu_cpu_starting up near the beginning of the start_secondary() function. Note that the raw_smp_processor_id() is required in order to avoid calling into lockdep before RCU has declared the CPU to be watched for readers. Link: https://lore.kernel.org/lkml/160223032121.7002.1269740091547117869.tip-bot2@tip-bot2/ Reported-by: Qian Cai <cai@redhat.com> Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-11-19Merge https://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski106-308/+765
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-19microblaze/mm/highmem: Add dropped #ifdef backThomas Gleixner1-0/+1
The conversion to generic kmap atomic broke microblaze by removing the build fail. Add it back. Fixes: 7ac1b26b0a72 ("microblaze/mm/highmem: Switch to generic kmap atomic") Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Michal Simek <monstr@monstr.eu>
2020-11-19Merge tag 'powerpc-cve-2020-4788' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linuxLinus Torvalds15-80/+421
Pull powerpc fixes from Michael Ellerman: "Fixes for CVE-2020-4788. From Daniel's cover letter: IBM Power9 processors can speculatively operate on data in the L1 cache before it has been completely validated, via a way-prediction mechanism. It is not possible for an attacker to determine the contents of impermissible memory using this method, since these systems implement a combination of hardware and software security measures to prevent scenarios where protected data could be leaked. However these measures don't address the scenario where an attacker induces the operating system to speculatively execute instructions using data that the attacker controls. This can be used for example to speculatively bypass "kernel user access prevention" techniques, as discovered by Anthony Steinhauser of Google's Safeside Project. This is not an attack by itself, but there is a possibility it could be used in conjunction with side-channels or other weaknesses in the privileged code to construct an attack. This issue can be mitigated by flushing the L1 cache between privilege boundaries of concern. This patch series flushes the L1 cache on kernel entry (patch 2) and after the kernel performs any user accesses (patch 3). It also adds a self-test and performs some related cleanups" * tag 'powerpc-cve-2020-4788' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/64s: rename pnv|pseries_setup_rfi_flush to _setup_security_mitigations selftests/powerpc: refactor entry and rfi_flush tests selftests/powerpc: entry flush test powerpc: Only include kup-radix.h for 64-bit Book3S powerpc/64s: flush L1D after user accesses powerpc/64s: flush L1D on kernel entry selftests/powerpc: rfi_flush: disable entry flush if present
2020-11-19Merge tag 'xtensa-20201119' of git://github.com/jcmvbkbc/linux-xtensaLinus Torvalds3-2/+16
Pull xtensa fixes from Max Filippov: - fix placement of cache alias remapping area - disable preemption around cache alias management calls - add missing __user annotation to strncpy_from_user argument * tag 'xtensa-20201119' of git://github.com/jcmvbkbc/linux-xtensa: xtensa: uaccess: Add missing __user to strncpy_from_user() prototype xtensa: disable preemption around cache alias management calls xtensa: fix TLBTEMP area placement
2020-11-19arm64: Ignore any DMA offsets in the max_zone_phys() calculationCatalin Marinas1-5/+12
Currently, the kernel assumes that if RAM starts above 32-bit (or zone_bits), there is still a ZONE_DMA/DMA32 at the bottom of the RAM and such constrained devices have a hardwired DMA offset. In practice, we haven't noticed any such hardware so let's assume that we can expand ZONE_DMA32 to the available memory if no RAM below 4GB. Similarly, ZONE_DMA is expanded to the 4GB limit if no RAM addressable by zone_bits. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Cc: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Cc: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/20201118185809.1078362-1-catalin.marinas@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-11-19x86/resctrl: Constify kernfs_opsRikard Falkeborn2-3/+3
The only usage of the kf_ops field in the rftype struct is to pass it as argument to __kernfs_create_file(), which accepts a pointer to const. Make it a pointer to const. This makes it possible to make rdtgroup_kf_single_ops and kf_mondata_ops const, which allows the compiler to put them in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lkml.kernel.org/r/20201110230228.801785-1-rikard.falkeborn@gmail.com
2020-11-19arm64: defconfig: Enable QCOM_SCM as builtinBjorn Andersson1-0/+1
The Qualcomm SCM driver was never explicitly enabled in the defconfig. Instead it was (apparently) selected by DRM_MSM and by the recent change to make it tristate now became =m. Unfortunately this removes the ability for PINCTRL_MSM and ARM_SMMU to be =y and with deferred_probe_timeout defaulting to 0 this means that things such as UART, USB, PCIe and SDHCI probes with their dependencies ignored. The lack of pinctrl results in invalid pin configuration and the lack of iommu results in the system locking up as soon as any form of data transfer is attempted from any of the affected peripherals. Mark QCOM_SCM as builtin, to avoid this. Reviewed-by: Vinod Koul <vkoul@kernel.org> Cc: John Stultz <john.stultz@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20201118162528.454729-1-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-11-19kvm: x86/mmu: Add TDP MMU SPTE changed trace pointBen Gardon2-0/+31
Add an extremely verbose trace point to the TDP MMU to log all SPTE changes, regardless of callstack / motivation. This is useful when a complete picture of the paging structure is needed or a change cannot be explained with the other, existing trace points. Tested: ran the demand paging selftest on an Intel Skylake machine with all the trace points used by the TDP MMU enabled and observed them firing with expected values. This patch can be viewed in Gerrit at: https://linux-review.googlesource.com/c/virt/kvm/kvm/+/3813 Signed-off-by: Ben Gardon <bgardon@google.com> Message-Id: <20201027175944.1183301-2-bgardon@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-11-19kvm: x86/mmu: Add existing trace points to TDP MMUBen Gardon1-1/+11
The TDP MMU was initially implemented without some of the usual tracepoints found in mmu.c. Correct this discrepancy by adding the missing trace points to the TDP MMU. Tested: ran the demand paging selftest on an Intel Skylake machine with all the trace points used by the TDP MMU enabled and observed them firing with expected values. This patch can be viewed in Gerrit at: https://linux-review.googlesource.com/c/virt/kvm/kvm/+/3812 Signed-off-by: Ben Gardon <bgardon@google.com> Message-Id: <20201027175944.1183301-1-bgardon@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-11-19ARM: dts: Configure power domain for omap5 dssTony Lindgren1-0/+1
This allows shutting down dss domain when the screen blanks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-19ARM: dts: omap5: add remaining PRM instancesTero Kristo1-0/+57
Add remaining PRM instances for the omap5 SoC. Additionally enable the genpd support for them. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-19ARM: OMAP2+: Drop legacy platform data for dra7 gpmcTony Lindgren2-64/+33
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. Cc: Roger Quadros <rogerq@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-19ARM: dts: Configure interconnect target module for dra7 ivaTony Lindgren2-0/+41
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Cc: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-19ARM: dts: dra7: add remaining PRM instancesTero Kristo1-0/+76
Add remaining PRM instances for the dra7 SoC. Additionally enable the genpd support for them. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-19powerpc/64s: rename pnv|pseries_setup_rfi_flush to _setup_security_mitigationsDaniel Axtens4-9/+11
pseries|pnv_setup_rfi_flush already does the count cache flush setup, and we just added entry and uaccess flushes. So the name is not very accurate any more. In both platforms we then also immediately setup the STF flush. Rename them to _setup_security_mitigations and fold the STF flush in. Signed-off-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2020-11-19powerpc: Only include kup-radix.h for 64-bit Book3SMichael Ellerman3-6/+11
In kup.h we currently include kup-radix.h for all 64-bit builds, which includes Book3S and Book3E. The latter doesn't make sense, Book3E never uses the Radix MMU. This has worked up until now, but almost by accident, and the recent uaccess flush changes introduced a build breakage on Book3E because of the bad structure of the code. So disentangle things so that we only use kup-radix.h for Book3S. This requires some more stubs in kup.h and fixing an include in syscall_64.c. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2020-11-19powerpc/64s: flush L1D after user accessesNicholas Piggin12-90/+229
IBM Power9 processors can speculatively operate on data in the L1 cache before it has been completely validated, via a way-prediction mechanism. It is not possible for an attacker to determine the contents of impermissible memory using this method, since these systems implement a combination of hardware and software security measures to prevent scenarios where protected data could be leaked. However these measures don't address the scenario where an attacker induces the operating system to speculatively execute instructions using data that the attacker controls. This can be used for example to speculatively bypass "kernel user access prevention" techniques, as discovered by Anthony Steinhauser of Google's Safeside Project. This is not an attack by itself, but there is a possibility it could be used in conjunction with side-channels or other weaknesses in the privileged code to construct an attack. This issue can be mitigated by flushing the L1 cache between privilege boundaries of concern. This patch flushes the L1 cache after user accesses. This is part of the fix for CVE-2020-4788. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2020-11-19powerpc/64s: flush L1D on kernel entryNicholas Piggin10-2/+197
IBM Power9 processors can speculatively operate on data in the L1 cache before it has been completely validated, via a way-prediction mechanism. It is not possible for an attacker to determine the contents of impermissible memory using this method, since these systems implement a combination of hardware and software security measures to prevent scenarios where protected data could be leaked. However these measures don't address the scenario where an attacker induces the operating system to speculatively execute instructions using data that the attacker controls. This can be used for example to speculatively bypass "kernel user access prevention" techniques, as discovered by Anthony Steinhauser of Google's Safeside Project. This is not an attack by itself, but there is a possibility it could be used in conjunction with side-channels or other weaknesses in the privileged code to construct an attack. This issue can be mitigated by flushing the L1 cache between privilege boundaries of concern. This patch flushes the L1 cache on kernel entry. This is part of the fix for CVE-2020-4788. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2020-11-19MIPS: Loongson64: Fix wrong scache size when execute lscpuTiezhu Yang1-6/+4
As the user manual and code comment said, Loongson-3 has 4-scache banks, while Loongson-2K has only 2 banks, so we should multiply the number of scache banks, this multiply operation should be done by c->scache.sets instead of scache_size, otherwise we will get the wrong scache size when execute lscpu. For example, the scache size should be 8192K instead of 2048K on the Loongson 3A3000 and 3A4000 platform, we can see the related info in the following boot message: [loongson@linux ~]$ dmesg | grep "Unified secondary cache" [ 0.000000] Unified secondary cache 8192kB 16-way, linesize 64 bytes. [ 4.061909] Unified secondary cache 8192kB 16-way, linesize 64 bytes. [ 4.125629] Unified secondary cache 8192kB 16-way, linesize 64 bytes. [ 4.188379] Unified secondary cache 8192kB 16-way, linesize 64 bytes. E.g. without this patch: [loongson@linux ~]$ cat /sys/devices/system/cpu/cpu*/cache/index2/size 2048K 2048K 2048K 2048K [loongson@linux ~]$ lscpu | grep "L2 cache" L2 cache: 2048K With this patch: [loongson@linux ~]$ cat /sys/devices/system/cpu/cpu*/cache/index2/size 8192K 8192K 8192K 8192K [loongson@linux ~]$ lscpu | grep "L2 cache" L2 cache: 8192K Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-11-19MIPS: Remove cpu_has_6k_cache and cpu_has_8k_cache in cpu_cache_init()Tiezhu Yang2-12/+0
Since commit 02cf2119684e ("Cleanup the mess in cpu_cache_init."), cpu_has_6k_cache and cpu_has_8k_cache have no user, r6k_cache_init() and r8k_cache_init() are not defined for over 15 years, just remove them. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-11-19MIPS: mm: Clean up setup of protection mapThomas Bogendoerfer2-44/+17
Protection map difference between RIXI and non RIXI cpus is _PAGE_NO_EXEC and _PAGE_NO_READ usage. Both already take care of cpu_has_rixi while setting up the page bits. So we just need one setup of protection map and can drop the now unused (and broken for RIXI) PAGE_* defines. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-11-19MIPS: mm: shorten lines by using macroThomas Bogendoerfer1-16/+20
Introduce helper macro to make lines shorter. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-11-19MIPS: kvm: Use vm_get_page_prot to get protection bitsThomas Bogendoerfer1-1/+3
MIPS protection bits are setup during runtime so using defines like PAGE_SHARED ignores this runtime changes. Using vm_get_page_prot to get correct page protection fixes this. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-11-19ARM: OMAP2+: Drop legacy platform data for omap4 gpmcTony Lindgren2-61/+33
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. Cc: Roger Quadros <rogerq@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-19ARM: OMAP2+: Drop legacy platform data for omap4 ivaTony Lindgren2-74/+26
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. Cc: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-19ARM: dts: Configure power domain for omap4 dspTony Lindgren1-0/+1
This allows shutting down the dsp domain when not in use. Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-19ARM: dts: Configure power domain for omap4 dssTony Lindgren1-0/+7
This allows shutting down dss domain when the screen blanks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-19ARM: dts: omap4: add remaining PRM instancesTero Kristo1-0/+63
Add remaining PRM instances for the omap4 SoC. Additionally enable the genpd support for them. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-19MIPS: vdso: Use vma page protection for remappingThomas Bogendoerfer1-2/+2
MIPS protection bits are setup during runtime so using defines like PAGE_READONLY ignores these runtime changes. To fix this we simply use the page protection of the setup vma. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-11-19ARM: dts: aspeed: ast2600evb: Add MAC0Joel Stanley1-0/+20
MAC0 was not functional in the AST2600A0 SoC. This has been resolved with the A1, so allow use of this port on EVBs with the A1 and subsequent revisions. A0 EVBs will still boot with this change, but the first Ethernet device will not be functional. Signed-off-by: Joel Stanley <joel@jms.id.au>
2020-11-19ARM: dts: aspeed: rainier: Don't shout addressesAndrew Jeffery1-2/+2
Make them lowercase. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20201002063414.275161-4-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
2020-11-19ARM: dts: aspeed: rainier: Mark FSI SPI controllers as restrictedEddie James1-0/+6
Some of the FSI-attached SPI controllers can't use the loop command due to security requirements. Indicate this in the devicetree with the restricted compatible string. Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20201102194713.14812-1-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2020-11-19rtc: rework rtc_register_device() resource managementBartosz Golaszewski1-1/+1
rtc_register_device() is a managed interface but it doesn't use devres by itself - instead it marks an rtc_device as "registered" and the devres callback for devm_rtc_allocate_device() takes care of resource release. This doesn't correspond with the design behind devres where managed structures should not be aware of being managed. The correct solution here is to register a separate devres callback for unregistering the device. While at it: rename rtc_register_device() to devm_rtc_register_device() and add it to the list of managed interfaces in devres.rst. This way we can avoid any potential confusion of driver developers who may expect there to exist a corresponding unregister function. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201109163409.24301-8-brgl@bgdev.pl
2020-11-19x86/topology: Set cpu_die_id only if DIE_TYPE foundYazen Ghannam1-2/+8
CPUID Leaf 0x1F defines a DIE_TYPE level (nb: ECX[8:15] level type == 0x5), but CPUID Leaf 0xB does not. However, detect_extended_topology() will set struct cpuinfo_x86.cpu_die_id regardless of whether a valid Die ID was found. Only set cpu_die_id if a DIE_TYPE level is found. CPU topology code may use another value for cpu_die_id, e.g. the AMD NodeId on AMD-based systems. Code ordering should be maintained so that the CPUID Leaf 0x1F Die ID value will take precedence on systems that may use another value. Suggested-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20201109210659.754018-5-Yazen.Ghannam@amd.com
2020-11-19x86/CPU/AMD: Remove amd_get_nb_id()Yazen Ghannam7-16/+8
The Last Level Cache ID is returned by amd_get_nb_id(). In practice, this value is the same as the AMD NodeId for callers of this function. The NodeId is saved in struct cpuinfo_x86.cpu_die_id. Replace calls to amd_get_nb_id() with the logical CPU's cpu_die_id and remove the function. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20201109210659.754018-3-Yazen.Ghannam@amd.com
2020-11-19x86/CPU/AMD: Save AMD NodeId as cpu_die_idYazen Ghannam4-17/+15
AMD systems provide a "NodeId" value that represents a global ID indicating to which "Node" a logical CPU belongs. The "Node" is a physical structure equivalent to a Die, and it should not be confused with logical structures like NUMA nodes. Logical nodes can be adjusted based on firmware or other settings whereas the physical nodes/dies are fixed based on hardware topology. The NodeId value can be used when a physical ID is needed by software. Save the AMD NodeId to struct cpuinfo_x86.cpu_die_id. Use the value from CPUID or MSR as appropriate. Default to phys_proc_id otherwise. Do so for both AMD and Hygon systems. Drop the node_id parameter from cacheinfo_*_init_llc_id() as it is no longer needed. Update the x86 topology documentation. Suggested-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20201109210659.754018-2-Yazen.Ghannam@amd.com
2020-11-19arm64: Rebuild sched domains on invariance status changesIonela Voinescu1-0/+10
Task scheduler behavior depends on frequency invariance (FI) support and the resulting invariant load tracking signals. For example, in order to make accurate predictions across CPUs for all performance states, Energy Aware Scheduling (EAS) needs frequency-invariant load tracking signals and therefore it has a direct dependency on FI. This dependency is known, but EAS enablement is not yet conditioned on the presence of FI during the built of the scheduling domain hierarchy. Before this is done, the following must be considered: while arch_scale_freq_invariant() will see changes in FI support and could be used to condition the use of EAS, it could return different values during system initialisation. For arm64, such a scenario will happen for a system that does not support cpufreq driven FI, but does support counter-driven FI. For such a system, arch_scale_freq_invariant() will return false if called before counter based FI initialisation, but change its status to true after it. If EAS becomes explicitly dependent on FI this would affect the task scheduler behavior which builds its scheduling domain hierarchy well before the late counter-based FI init. During that process, EAS would be disabled due to its dependency on FI. Two points of future early calls to arch_scale_freq_invariant() which would determine EAS enablement are: - (1) drivers/base/arch_topology.c:126 <<update_topology_flags_workfn>> rebuild_sched_domains(); This will happen after CPU capacity initialisation. - (2) kernel/sched/cpufreq_schedutil.c:917 <<rebuild_sd_workfn>> rebuild_sched_domains_energy(); -->rebuild_sched_domains(); This will happen during sched_cpufreq_governor_change() for the schedutil cpufreq governor. Therefore, before enforcing the presence of FI support for the use of EAS, ensure the following: if there is a change in FI support status after counter init, use the existing rebuild_sched_domains_energy() function to trigger a rebuild of the scheduling and performance domains that in turn will determine the enablement of EAS. Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lkml.kernel.org/r/20201027180713.7642-3-ionela.voinescu@arm.com
2020-11-19x86: Support HAVE_CONTEXT_TRACKING_OFFSTACKFrederic Weisbecker1-0/+1
A lot of ground work has been performed on x86 entry code. Fragile path between user_enter() and user_exit() have IRQs disabled. Uses of RCU and intrumentation in these fragile areas have been explicitly annotated and protected. This architecture doesn't need exception_enter()/exception_exit() anymore and has therefore earned CONFIG_HAVE_CONTEXT_TRACKING_OFFSTACK. Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20201117151637.259084-6-frederic@kernel.org
2020-11-19context_tracking: Introduce HAVE_CONTEXT_TRACKING_OFFSTACKFrederic Weisbecker1-0/+17
Historically, context tracking had to deal with fragile entry code path, ie: before user_exit() is called and after user_enter() is called, in case some of those spots would call schedule() or use RCU. On such cases, the site had to be protected between exception_enter() and exception_exit() that save the context tracking state in the task stack. Such sleepable fragile code path had many different origins: tracing, exceptions, early or late calls to context tracking on syscalls... Aside of that not being pretty, saving the context tracking state on the task stack forces us to run context tracking on all CPUs, including housekeepers, and prevents us to completely shutdown nohz_full at runtime on a CPU in the future as context tracking and its overhead would still need to run system wide. Now thanks to the extensive efforts to sanitize x86 entry code, those conditions have been removed and we can now get rid of these workarounds in this architecture. Create a Kconfig feature to express this achievement. Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20201117151637.259084-2-frederic@kernel.org
2020-11-19x86/sgx: Return -ERESTARTSYS in sgx_ioc_enclave_add_pages()Jarkko Sakkinen1-1/+1
Return -ERESTARTSYS instead of -EINTR in sgx_ioc_enclave_add_pages() when interrupted before any pages have been processed. At this point ioctl can be obviously safely restarted. Reported-by: Haitao Huang <haitao.huang@intel.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20201118213932.63341-1-jarkko@kernel.org
2020-11-19Merge tag 'x86-urgent-2020-11-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip into for-next/iommu/fixesWill Deacon2-13/+3
Pull in x86 fixes from Thomas, as they include a change to the Intel DMAR code on which we depend: * tag 'x86-urgent-2020-11-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: iommu/vt-d: Cure VF irqdomain hickup x86/platform/uv: Fix copied UV5 output archtype x86/platform/uv: Drop last traces of uv_flush_tlb_others
2020-11-19x86/msr: Downgrade unrecognized MSR messageBorislav Petkov1-2/+2
It is a warning and not an error so use pr_warn(). Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20201118123806.19672-1-bp@alien8.de
2020-11-19ARM: OMAP1: clock: Use IS_ERR_OR_NULL() to clean codeTang Bin1-7/+7
Use IS_ERR_OR_NULL() to make the code cleaner. Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com> Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-19ARM: OMAP2+: Remove redundant null check before clk_prepare_enable/clk_disable_unprepareXu Wang1-4/+2
Because clk_prepare_enable() and clk_disable_unprepare() already checked NULL clock parameter, so the additional checks are unnecessary, just remove them. Signed-off-by: Xu Wang <vulab@iscas.ac.cn> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-19ARM: OMAP2+: Remove redundant assignment to variable retJing Xiangfeng1-3/+2
The variable ret has been initialized with '-ENOMEM'. The assignment in the if branch is redundant. So remove it. Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-19ARM: OMAP2+: Fix kfree NULL pointer in omap2xxx_clkt_vps_initYouling Tang1-4/+1
The returns pointer is NULL when kzalloc fails to apply for space, so fix kfree NULL pointer. Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-19ARM: OMAP2+: Fix memleak in omap2xxx_clkt_vps_initYouling Tang1-0/+6
If the clk_register fails, we should free hw before function returns to prevent memleak. Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-19ARM: dts: dra76x: m_can: fix order of clocksMarc Kleine-Budde1-2/+2
According to the bosch,m_can.yaml bindings the first clock shall be the "hclk", while the second clock "cclk". This patch fixes the order accordingly. Fixes: 0adbe832f21a ("ARM: dts: dra76x: Add MCAN node") Cc: Faiz Abbas <faiz_abbas@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: linux-omap@vger.kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Tony Lindgren <tony@atomide.com>