aboutsummaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2022-06-03KVM: x86: hyper-v: replace bitmap_weight() with hweight64()Yury Norov1-2/+2
kvm_hv_flush_tlb() applies bitmap API to a u64 variable valid_bank_mask. Since valid_bank_mask has a fixed size, we can use hweight64() and avoid excessive bloating. CC: Borislav Petkov <[email protected]> CC: Dave Hansen <[email protected]> CC: H. Peter Anvin <[email protected]> CC: Ingo Molnar <[email protected]> CC: Jim Mattson <[email protected]> CC: Joerg Roedel <[email protected]> CC: Paolo Bonzini <[email protected]> CC: Sean Christopherson <[email protected]> CC: Thomas Gleixner <[email protected]> CC: Vitaly Kuznetsov <[email protected]> CC: Wanpeng Li <[email protected]> CC: [email protected] CC: [email protected] CC: [email protected] Acked-by: Vitaly Kuznetsov <[email protected]> Signed-off-by: Yury Norov <[email protected]>
2022-06-03KVM: x86: hyper-v: fix type of valid_bank_maskYury Norov1-2/+2
In kvm_hv_flush_tlb(), valid_bank_mask is declared as unsigned long, but is used as u64, which is wrong for i386, and has been spotted by LKP after applying "KVM: x86: hyper-v: replace bitmap_weight() with hweight64()" https://lore.kernel.org/lkml/[email protected]/ But it's wrong even without that patch because now bitmap_weight() dereferences a word after valid_bank_mask on i386. >> include/asm-generic/bitops/const_hweight.h:21:76: warning: right shift count >= width of type +[-Wshift-count-overflow] 21 | #define __const_hweight64(w) (__const_hweight32(w) + __const_hweight32((w) >> 32)) | ^~ include/asm-generic/bitops/const_hweight.h:10:16: note: in definition of macro '__const_hweight8' 10 | ((!!((w) & (1ULL << 0))) + \ | ^ include/asm-generic/bitops/const_hweight.h:20:31: note: in expansion of macro '__const_hweight16' 20 | #define __const_hweight32(w) (__const_hweight16(w) + __const_hweight16((w) >> 16)) | ^~~~~~~~~~~~~~~~~ include/asm-generic/bitops/const_hweight.h:21:54: note: in expansion of macro '__const_hweight32' 21 | #define __const_hweight64(w) (__const_hweight32(w) + __const_hweight32((w) >> 32)) | ^~~~~~~~~~~~~~~~~ include/asm-generic/bitops/const_hweight.h:29:49: note: in expansion of macro '__const_hweight64' 29 | #define hweight64(w) (__builtin_constant_p(w) ? __const_hweight64(w) : __arch_hweight64(w)) | ^~~~~~~~~~~~~~~~~ arch/x86/kvm/hyperv.c:1983:36: note: in expansion of macro 'hweight64' 1983 | if (hc->var_cnt != hweight64(valid_bank_mask)) | ^~~~~~~~~ CC: Borislav Petkov <[email protected]> CC: Dave Hansen <[email protected]> CC: H. Peter Anvin <[email protected]> CC: Ingo Molnar <[email protected]> CC: Jim Mattson <[email protected]> CC: Joerg Roedel <[email protected]> CC: Paolo Bonzini <[email protected]> CC: Sean Christopherson <[email protected]> CC: Thomas Gleixner <[email protected]> CC: Vitaly Kuznetsov <[email protected]> CC: Wanpeng Li <[email protected]> CC: [email protected] CC: [email protected] CC: [email protected] Reported-by: kernel test robot <[email protected]> Signed-off-by: Yury Norov <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2022-06-03ia64: cleanup remove_siblinginfo()Yury Norov1-4/+0
remove_siblinginfo() initialises variable 'last', but never uses it. Drop unneeded code. CC: Ingo Molnar <[email protected]> CC: Peter Zijlstra <[email protected]> CC: Valentin Schneider <[email protected]> CC: [email protected] CC: [email protected] Signed-off-by: Yury Norov <[email protected]> Acked-by: Andrew Morton <[email protected]>
2022-06-03KVM: s390: replace bitmap_copy with bitmap_{from,to}_arr64 where appropriateYury Norov1-7/+3
Copying bitmaps from/to 64-bit arrays with bitmap_copy is not safe on 32-bit BE machines. Use designated functions instead. CC: Alexander Gordeev <[email protected]> CC: Andy Shevchenko <[email protected]> CC: Christian Borntraeger <[email protected]> CC: Claudio Imbrenda <[email protected]> CC: David Hildenbrand <[email protected]> CC: Heiko Carstens <[email protected]> CC: Janosch Frank <[email protected]> CC: Rasmus Villemoes <[email protected]> CC: Sven Schnelle <[email protected]> CC: Vasily Gorbik <[email protected]> Signed-off-by: Yury Norov <[email protected]> Reviewed-by: David Hildenbrand <[email protected]>
2022-06-03arch/x86: replace nodes_weight with nodes_empty where appropriateYury Norov2-3/+3
mm code calls nodes_weight() to check if any bit of a given nodemask is set. We can do it more efficiently with nodes_empty() because nodes_empty() stops traversing the nodemask as soon as it finds first set bit, while nodes_weight() counts all bits unconditionally. Signed-off-by: Yury Norov <[email protected]>
2022-06-03arch/x86: replace cpumask_weight with cpumask_empty where appropriateYury Norov3-9/+9
In some cases, arch/x86 code calls cpumask_weight() to check if any bit of a given cpumask is set. We can do it more efficiently with cpumask_empty() because cpumask_empty() stops traversing the cpumask as soon as it finds first set bit, while cpumask_weight() counts all bits unconditionally. Signed-off-by: Yury Norov <[email protected]> Reviewed-by: Steve Wahl <[email protected]>
2022-06-03arch/ia64: replace cpumask_weight with cpumask_empty where appropriateYury Norov1-1/+1
setup_arch() calls cpumask_weight() to check if any bit of a given cpumask is set. We can do it more efficiently with cpumask_empty() because cpumask_empty() stops traversing the cpumask as soon as it finds first set bit, while cpumask_weight() counts all bits unconditionally. Signed-off-by: Yury Norov <[email protected]>
2022-06-03arch/alpha: replace cpumask_weight with cpumask_empty where appropriateYury Norov1-1/+1
common_shutdown_1() calls cpumask_weight() to check if any bit of a given cpumask is set. We can do it more efficiently with cpumask_empty() because cpumask_empty() stops traversing the cpumask as soon as it finds first set bit, while cpumask_weight() counts all bits unconditionally. Signed-off-by: Yury Norov <[email protected]>
2022-06-03risc-v: replace bitmap_weight with bitmap_empty in riscv_fill_hwcap()Yury Norov1-4/+3
bitmap_empty() is better than bitmap_weight() because it may return earlier, and improves on readability. CC: Albert Ou <[email protected]> CC: Anup Patel <[email protected]> CC: Atish Patra <[email protected]> CC: Jisheng Zhang <[email protected]> CC: Palmer Dabbelt <[email protected]> CC: Paul Walmsley <[email protected]> CC: Tsukasa OI <[email protected]> CC: [email protected] CC: [email protected] Signed-off-by: Yury Norov <[email protected]> Reviewed-by: Anup Patel <[email protected]>
2022-06-03LoongArch: Add Loongson-3 default config fileHuacai Chen2-0/+773
Add a default config file for LoongArch-based Loongson-3 platform. Reviewed-by: WANG Xuerui <[email protected]> Reviewed-by: Jiaxun Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-06-03LoongArch: Add Non-Uniform Memory Access (NUMA) supportHuacai Chen17-29/+844
Add Non-Uniform Memory Access (NUMA) support for LoongArch. LoongArch has 48-bit physical address, but the HyperTransport I/O bus only support 40-bit address, so we need a custom phys_to_dma() and dma_to_phys() to extract the 4-bit node id (bit 44~47) from Loongson-3's 48-bit physical address space and embed it into 40-bit. In the 40-bit dma address, node id offset can be read from the LS7A_DMA_CFG register. Reviewed-by: WANG Xuerui <[email protected]> Reviewed-by: Jiaxun Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-06-03LoongArch: Add multi-processor (SMP) supportHuacai Chen26-10/+1549
LoongArch-based procesors have 4, 8 or 16 cores per package. This patch adds multi-processor (SMP) support for LoongArch. Reviewed-by: WANG Xuerui <[email protected]> Reviewed-by: Jiaxun Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-06-03LoongArch: Add VDSO and VSYSCALL supportHuacai Chen15-0/+622
Add VDSO and VSYSCALL support (sigreturn, gettimeofday and its friends) for LoongArch. Reviewed-by: WANG Xuerui <[email protected]> Reviewed-by: Jiaxun Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-06-03LoongArch: Add some library functionsHuacai Chen6-0/+282
Add some library functions for LoongArch, including: delay, memset, memcpy, memmove, copy_user, strncpy_user, strnlen_user and tlb dump functions. Reviewed-by: WANG Xuerui <[email protected]> Reviewed-by: Jiaxun Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-06-03LoongArch: Add misc common routinesHuacai Chen7-0/+734
Add some misc common routines for LoongArch, including: asm-offsets routines, futex functions, i/o memory access functions, frame-buffer functions, procfs information display, etc. Reviewed-by: WANG Xuerui <[email protected]> Reviewed-by: Jiaxun Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-06-03LoongArch: Add ELF and module supportHuacai Chen12-0/+1043
Add ELF-related definition and module relocation code for basic LoongArch support. Cc: Jessica Yu <[email protected]> Reviewed-by: WANG Xuerui <[email protected]> Reviewed-by: Luis Chamberlain <[email protected]> Reviewed-by: Jiaxun Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-06-03LoongArch: Add signal handling supportHuacai Chen4-0/+658
Add ucontext/sigcontext definition and signal handling support for LoongArch. Cc: Eric Biederman <[email protected]> Cc: Al Viro <[email protected]> Reviewed-by: WANG Xuerui <[email protected]> Reviewed-by: Jiaxun Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-06-03LoongArch: Add system call supportHuacai Chen7-0/+531
Add system call support and related uaccess.h for LoongArch. Q: Why keep _ARCH_WANT_SYS_CLONE definition while there is clone3: A: The latest glibc release has some basic support for clone3 but it is not complete. E.g., pthread_create() and spawni() have converted to use clone3 but fork() will still use clone. Moreover, some seccomp related applications can still not work perfectly with clone3. E.g., Chromium sandbox cannot work at all and there is no solution for it, which is more terrible than the fork() story [1]. [1] https://chromium-review.googlesource.com/c/chromium/src/+/2936184 Reviewed-by: WANG Xuerui <[email protected]> Reviewed-by: Jiaxun Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-06-03LoongArch: Add memory managementHuacai Chen26-0/+3172
Add memory management support for LoongArch, including: cache and tlb management, page fault handling and ioremap/mmap support. Reviewed-by: WANG Xuerui <[email protected]> Reviewed-by: Jiaxun Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-06-03LoongArch: Add process managementHuacai Chen14-0/+1865
Add process management support for LoongArch, including: thread info definition, context switch and process tracing. Reviewed-by: WANG Xuerui <[email protected]> Reviewed-by: Jiaxun Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-06-03LoongArch: Add exception/interrupt handlingHuacai Chen16-0/+1575
Add the exception and interrupt handling machanism for basic LoongArch support. Reviewed-by: WANG Xuerui <[email protected]> Reviewed-by: Jiaxun Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-06-03LoongArch: Add boot and setup routinesHuacai Chen18-0/+1738
Add basic boot, setup and reset routines for LoongArch. Now, LoongArch machines use UEFI-based firmware. The firmware passes configuration information to the kernel via ACPI and DMI/SMBIOS. Currently an existing interface between the kernel and the bootloader is implemented. Kernel gets 2 values from the bootloader, passed in registers a0 and a1; a0 is an "EFI boot flag" distinguishing UEFI and non-UEFI firmware, while a1 is a pointer to an FDT with systable, memmap, cmdline and initrd information. The standard UEFI boot protocol (EFISTUB) will be added later. Cc: [email protected] Cc: Ard Biesheuvel <[email protected]> Reviewed-by: WANG Xuerui <[email protected]> Reviewed-by: Jiaxun Yang <[email protected]> Co-developed-by: Yun Liu <[email protected]> Signed-off-by: Yun Liu <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-06-03LoongArch: Add other common headersHuacai Chen17-0/+915
Add some other common headers for basic LoongArch support. Reviewed-by: WANG Xuerui <[email protected]> Reviewed-by: Jiaxun Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-06-03LoongArch: Add atomic/locking headersHuacai Chen7-0/+756
Add common headers (atomic, bitops, barrier and locking) for basic LoongArch support. Reviewed-by: WANG Xuerui <[email protected]> Reviewed-by: Jiaxun Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-06-03LoongArch: Add CPU definition headersHuacai Chen8-0/+2191
Add common headers (CPU definition and address space layout) for basic LoongArch support. Reviewed-by: WANG Xuerui <[email protected]> Reviewed-by: Jiaxun Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-06-03LoongArch: Add build infrastructureHuacai Chen16-0/+700
Add Kbuild, Makefile, Kconfig and link script for LoongArch build infrastructure. Reviewed-by: Guo Ren <[email protected]> Reviewed-by: WANG Xuerui <[email protected]> Reviewed-by: Jiaxun Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-06-03parisc: fix a crash with multicore schedulerMikulas Patocka2-17/+1
With the kernel 5.18, the system will hang on boot if it is compiled with CONFIG_SCHED_MC. The last printed message is "Brought up 1 node, 1 CPU". The crash happens in sd_init tl->mask (which is cpu_coregroup_mask) returns an empty mask. This happens because cpu_topology[0].core_sibling is empty. Consequently, sd_span is set to an empty mask sd_id = cpumask_first(sd_span) sets sd_id == NR_CPUS (because the mask is empty) sd->shared = *per_cpu_ptr(sdd->sds, sd_id); sets sd->shared to NULL because sd_id is out of range atomic_inc(&sd->shared->ref); crashes without printing anything We can fix it by calling reset_cpu_topology() from init_cpu_topology() - this will initialize the sibling masks on CPUs, so that they're not empty. This patch also removes the variable "dualcores_found", it is useless, because during boot, init_cpu_topology is called before store_cpu_topology. Thus, set_sched_topology(parisc_mc_topology) is never called. We don't need to call it at all because default_topology in kernel/sched/topology.c contains the same items as parisc_mc_topology. Note that we should not call store_cpu_topology() from init_per_cpu() because it is called too early in the kernel initialization process and it results in the message "Failure to register CPU0 device". Before this patch, store_cpu_topology() would exit immediatelly because cpuid_topo->core id was uninitialized and it was 0. Signed-off-by: Mikulas Patocka <[email protected]> Cc: [email protected] # v5.18 Signed-off-by: Helge Deller <[email protected]>
2022-06-02riscv: Move alternative length validation into subsectionNathan Chancellor1-2/+2
After commit 49b290e430d3 ("riscv: prevent compressed instructions in alternatives"), builds with LLVM's integrated assembler fail: In file included from arch/riscv/mm/init.c:10: In file included from ./include/linux/mm.h:29: In file included from ./include/linux/pgtable.h:6: In file included from ./arch/riscv/include/asm/pgtable.h:108: ./arch/riscv/include/asm/tlbflush.h:23:2: error: expected assembly-time absolute expression ALT_FLUSH_TLB_PAGE(__asm__ __volatile__ ("sfence.vma %0" : : "r" (addr) : "memory")); ^ ./arch/riscv/include/asm/errata_list.h:33:5: note: expanded from macro 'ALT_FLUSH_TLB_PAGE' asm(ALTERNATIVE("sfence.vma %0", "sfence.vma", SIFIVE_VENDOR_ID, \ ^ ./arch/riscv/include/asm/alternative-macros.h:187:2: note: expanded from macro 'ALTERNATIVE' _ALTERNATIVE_CFG(old_content, new_content, vendor_id, errata_id, CONFIG_k) ^ ./arch/riscv/include/asm/alternative-macros.h:113:2: note: expanded from macro '_ALTERNATIVE_CFG' __ALTERNATIVE_CFG(old_c, new_c, vendor_id, errata_id, IS_ENABLED(CONFIG_k)) ^ ./arch/riscv/include/asm/alternative-macros.h:110:2: note: expanded from macro '__ALTERNATIVE_CFG' ALT_NEW_CONTENT(vendor_id, errata_id, enable, new_c) ^ ./arch/riscv/include/asm/alternative-macros.h:99:3: note: expanded from macro 'ALT_NEW_CONTENT' ".org . - (889b - 888b) + (887b - 886b)\n" \ ^ <inline asm>:26:6: note: instantiated into assembly here .org . - (889b - 888b) + (887b - 886b) ^ This error happens because LLVM's integrated assembler has a one-pass design, which means it cannot figure out the instruction lengths when the .org directive is outside of the subsection that contains the instructions, which was changed by the .option directives added by the above change. Move the .org directives before the .previous directive so that these directives are always within the same subsection, which resolves the failures and does not introduce any new issues with GNU as. This was done for arm64 in commit 966a0acce2fc ("arm64/alternatives: move length validation inside the subsection") and commit 22315a2296f4 ("arm64: alternatives: Move length validation in alternative_{insn, endif}"). While there is no error from the assembly versions of the macro, they appear to have the same problem so just make the same change there as well so that there are no problems in the future. Link: https://github.com/ClangBuiltLinux/linux/issues/1640 Reported-by: kernel test robot <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2022-06-02Merge tag 'asm-generic-fixes-5.19' of ↵Linus Torvalds3-10/+10
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic Pull asm-generic fixes from Arnd Bergmann: "The header cleanup series from Masahiro Yamada ended up causing some regressions in the ABI because of an ambigous uid_t type. This was only caught after the original patches got merged, but at least the fixes are trivial and hopefully complete" * tag 'asm-generic-fixes-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic: binder: fix sender_euid type in uapi header sparc: fix mis-use of __kernel_{uid,gid}_t in uapi/asm/stat.h powerpc: use __kernel_{uid,gid}32_t in uapi/asm/stat.h mips: use __kernel_{uid,gid}32_t in uapi/asm/stat.h
2022-06-02Merge tag 'arm-late-5.19' of ↵Linus Torvalds48-97/+836
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull more ARM SoC updates from Arnd Bergmann: "This is the second part of the general SoC updates, containing everything that did not make it in the initial pull request, or that came in as a bugfix later. - Devicetree updates for SoCFPGA, ASPEED, AT91 and Rockchip, including a new machine using an ASPEED BMC. - More DT fixes from Krzysztof Kozlowski across platforms - A new SoC platform for the GXP baseboard management controller, used in current server products from HPE" * tag 'arm-late-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (56 commits) ARM: configs: Enable more audio support for i.MX tee: optee: Pass a pointer to virt_addr_valid() arm64: dts: rockchip: rename Quartz64-A bluetooth gpios arm64: dts: rockchip: add clocks property to cru node rk3368 arm64: dts: rockchip: add clocks property to cru node rk3308 arm64: dts: rockchip: add clocks to rk356x cru ARM: dts: rockchip: add clocks property to cru node rk3228 ARM: dts: rockchip: add clocks property to cru node rk3036 ARM: dts: rockchip: add clocks property to cru node rk3066a/rk3188 ARM: dts: rockchip: add clocks property to cru node rk3288 ARM: dts: rockchip: Remove "amba" bus nodes from rv1108 ARM: dts: rockchip: add clocks property to cru node rv1108 arm64: dts: sprd: use new 'dma-channels' property ARM: dts: da850: use new 'dma-channels' property ARM: dts: pxa: use new 'dma-channels/requests' properties soc: ixp4xx/qmgr: Fix unused match warning ARM: ep93xx: Make ts72xx_register_flash() static ARM: configs: enable support for Kontron KSwitch D10 ep93xx: clock: Do not return the address of the freed memory arm64: dts: intel: add device tree for n6000 ...
2022-06-02Merge tag 'arm-multiplatform-5.19-2' of ↵Linus Torvalds180-2564/+2226
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull more ARM multiplatform updates from Arnd Bergmann: "The second part of the multiplatform changes now converts the Intel/Marvell PXA platform along with the rest. The patches went through several rebases before the merge window as bugs were found, so they remained separate. This has to touch a lot of drivers, in particular the touchscreen, pcmcia, sound and clk bits, to detach the driver files from the platform and board specific header files" * tag 'arm-multiplatform-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (48 commits) ARM: pxa/mmp: remove traces of plat-pxa ARM: pxa: convert to multiplatform ARM: pxa/sa1100: move I/O space to PCI_IOBASE ARM: pxa: remove support for MTD_XIP ARM: pxa: move mach/*.h to mach-pxa/ ARM: PXA: fix multi-cpu build of xsc3 ARM: pxa: move plat-pxa to drivers/soc/ ARM: mmp: rename pxa_register_device ARM: mmp: remove tavorevb board support ARM: pxa: remove unused mach/bitfield.h ARM: pxa: move clk register definitions to driver ARM: pxa: move smemc register access from clk to platform cpufreq: pxa3: move clk register access to clk driver ARM: pxa: remove get_clk_frequency_khz() ARM: pxa: pcmcia: move smemc configuration back to arch ASoC: pxa: i2s: use normal MMIO accessors ASoC: pxa: ac97: use normal MMIO accessors ASoC: pxa: use pdev resource for FIFO regs Input: wm97xx - get rid of irq_enable method in wm97xx_mach_ops Input: wm97xx - switch to using threaded IRQ ...
2022-06-02riscv: mm: init: make pt_ops_set_[early|late|fixmap] staticJisheng Zhang1-3/+3
These three functions are only used in init.c, so make them static. Fix W=1 warnings like below: arch/riscv/mm/init.c:721:13: warning: no previous prototype for function 'pt_ops_set_early' [-Wmissing-prototypes] void __init pt_ops_set_early(void) ^ Signed-off-by: Jisheng Zhang <[email protected]> Reviewed-by: Anup Patel <[email protected]> Reviewed-by: Atish Patra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2022-06-02arm64: Initialize jump labels before setup_machine_fdt()Stephen Boyd1-3/+4
A static key warning splat appears during early boot on arm64 systems that credit randomness from devicetrees that contain an "rng-seed" property. This is because setup_machine_fdt() is called before jump_label_init() during setup_arch(). Let's swap the order of these two calls so that jump labels are initialized before the devicetree is unflattened and the rng seed is credited. static_key_enable_cpuslocked(): static key '0xffffffe51c6fcfc0' used before call to jump_label_init() WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:166 static_key_enable_cpuslocked+0xb0/0xb8 Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0+ #224 44b43e377bfc84bc99bb5ab885ff694984ee09ff pstate: 600001c9 (nZCv dAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : static_key_enable_cpuslocked+0xb0/0xb8 lr : static_key_enable_cpuslocked+0xb0/0xb8 sp : ffffffe51c393cf0 x29: ffffffe51c393cf0 x28: 000000008185054c x27: 00000000f1042f10 x26: 0000000000000000 x25: 00000000f10302b2 x24: 0000002513200000 x23: 0000002513200000 x22: ffffffe51c1c9000 x21: fffffffdfdc00000 x20: ffffffe51c2f0831 x19: ffffffe51c6fcfc0 x18: 00000000ffff1020 x17: 00000000e1e2ac90 x16: 00000000000000e0 x15: ffffffe51b710708 x14: 0000000000000066 x13: 0000000000000018 x12: 0000000000000000 x11: 0000000000000000 x10: 00000000ffffffff x9 : 0000000000000000 x8 : 0000000000000000 x7 : 61632065726f6665 x6 : 6220646573752027 x5 : ffffffe51c641d25 x4 : ffffffe51c13142c x3 : ffff0a00ffffff05 x2 : 40000000ffffe003 x1 : 00000000000001c0 x0 : 0000000000000065 Call trace: static_key_enable_cpuslocked+0xb0/0xb8 static_key_enable+0x2c/0x40 crng_set_ready+0x24/0x30 execute_in_process_context+0x80/0x90 _credit_init_bits+0x100/0x154 add_bootloader_randomness+0x64/0x78 early_init_dt_scan_chosen+0x140/0x184 early_init_dt_scan_nodes+0x28/0x4c early_init_dt_scan+0x40/0x44 setup_machine_fdt+0x7c/0x120 setup_arch+0x74/0x1d8 start_kernel+0x84/0x44c __primary_switched+0xc0/0xc8 ---[ end trace 0000000000000000 ]--- random: crng init done Machine model: Google Lazor (rev1 - 2) with LTE Cc: Hsin-Yi Wang <[email protected]> Cc: Douglas Anderson <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Jason A. Donenfeld <[email protected]> Cc: Dominik Brodowski <[email protected]> Fixes: f5bda35fba61 ("random: use static branch for crng_ready()") Signed-off-by: Stephen Boyd <[email protected]> Reviewed-by: Jason A. Donenfeld <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2022-06-02arm64: hibernate: Fix syntax errors in commentsXiang wangx1-1/+1
Delete the redundant word 'to'. Signed-off-by: Xiang wangx <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2022-06-02x86/sgx: Set active memcg prior to shmem allocationKristen Carlson Accardi3-6/+115
When the system runs out of enclave memory, SGX can reclaim EPC pages by swapping to normal RAM. These backing pages are allocated via a per-enclave shared memory area. Since SGX allows unlimited over commit on EPC memory, the reclaimer thread can allocate a large number of backing RAM pages in response to EPC memory pressure. When the shared memory backing RAM allocation occurs during the reclaimer thread context, the shared memory is charged to the root memory control group, and the shmem usage of the enclave is not properly accounted for, making cgroups ineffective at limiting the amount of RAM an enclave can consume. For example, when using a cgroup to launch a set of test enclaves, the kernel does not properly account for 50% - 75% of shmem page allocations on average. In the worst case, when nearly all allocations occur during the reclaimer thread, the kernel accounts less than a percent of the amount of shmem used by the enclave's cgroup to the correct cgroup. SGX stores a list of mm_structs that are associated with an enclave. Pick one of them during reclaim and charge that mm's memcg with the shmem allocation. The one that gets picked is arbitrary, but this list almost always only has one mm. The cases where there is more than one mm with different memcg's are not worth considering. Create a new function - sgx_encl_alloc_backing(). This function is used whenever a new backing storage page needs to be allocated. Previously the same function was used for page allocation as well as retrieving a previously allocated page. Prior to backing page allocation, if there is a mm_struct associated with the enclave that is requesting the allocation, it is set as the active memory control group. [ dhansen: - fix merge conflict with ELDU fixes - check against actual ksgxd_tsk, not ->mm ] Cc: [email protected] Signed-off-by: Kristen Carlson Accardi <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Reviewed-by: Shakeel Butt <[email protected]> Acked-by: Roman Gushchin <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2022-06-02Merge tag 'livepatching-for-5.19' of ↵Linus Torvalds5-53/+2
git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching Pull livepatching cleanup from Petr Mladek: - Remove duplicated livepatch code [Christophe] * tag 'livepatching-for-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching: livepatch: Remove klp_arch_set_pc() and asm/livepatch.h
2022-06-02sparc: fix mis-use of __kernel_{uid,gid}_t in uapi/asm/stat.hMasahiro Yamada1-2/+2
Commit 31a088b664d6 ("sparc: add asm/stat.h to UAPI compile-test coverage") converted as follows: uid_t --> __kernel_uid_t gid_t --> __kernel_gid_t It changed the field widths of struct stat because Sparc uses 16-bits for ___kernel_{uid,gid}_t as in arch/sparc/include/uapi/asm/posix_types.h. The safe replacements across all architectures are: uid_t --> __kernel_uid32_t gid_t --> __kernel_gid32_t as defined in include/linux/types.h. A similar issue was reported for the android binder. [1] [1]: https://lore.kernel.org/all/[email protected]/ Fixes: 31a088b664d6 ("sparc: add asm/stat.h to UAPI compile-test coverage") Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2022-06-02powerpc: use __kernel_{uid,gid}32_t in uapi/asm/stat.hMasahiro Yamada1-2/+2
Commit c01013a2f8dd ("powerpc: add asm/stat.h to UAPI compile-test coverage") converted as follows: uid_t --> __kernel_uid_t gid_t --> __kernel_gid_t The bit width of __kernel_{uid,gid}_t is 16 or 32-bits depending on architectures. PPC uses 32-bits for them as in include/uapi/asm-generic/posix_types.h, so the previous conversion is probably fine, but let's stick to the arch-independent conversion just in case. The safe replacements across all architectures are: uid_t --> __kernel_uid32_t gid_t --> __kernel_gid32_t as defined in include/linux/types.h. A similar issue was reported for the android binder. [1] [1]: https://lore.kernel.org/all/[email protected]/ Fixes: c01013a2f8dd ("powerpc: add asm/stat.h to UAPI compile-test coverage") Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2022-06-02mips: use __kernel_{uid,gid}32_t in uapi/asm/stat.hMasahiro Yamada1-6/+6
Commit 8c1a381a4fbb ("mips: add asm/stat.h to UAPI compile-test coverage") converted as follows: uid_t --> __kernel_uid_t gid_t --> __kernel_gid_t The bit width of __kernel_{uid,gid}_t is 16 or 32-bits depending on architectures. MIPS uses 32-bits for them as in include/uapi/asm-generic/posix_types.h, so the previous conversion is probably fine, but let's stick to the arch-independent conversion just in case. The safe replacements across all architectures are: uid_t --> __kernel_uid32_t gid_t --> __kernel_gid32_t as defined in include/linux/types.h. A similar issue was reported for the android binder. [1] [1]: https://lore.kernel.org/all/[email protected]/ Fixes: 8c1a381a4fbb ("mips: add asm/stat.h to UAPI compile-test coverage") Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2022-06-02arm64: Remove the __user annotation for the restore_za_context() argumentCatalin Marinas1-1/+1
The struct user_ctx *user pointer passed to restore_za_context() is not a user point but a structure containing several __user pointers. Remove the __user annotation. Signed-off-by: Catalin Marinas <[email protected]> Fixes: 39782210eb7e ("arm64/sme: Implement ZA signal handling") Reported-by: kernel test robot <[email protected]> Cc: Mark Brown <[email protected]> Reviewed-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2022-06-01riscv: move errata/ and kvm/ builds to arch/riscv/KbuildMasahiro Yamada2-3/+2
Commit 909548d6c578 ("riscv: add arch/riscv/Kbuild") intended that subdirectories in arch/riscv/ would be added in arch/riscv/Kbuild. Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Anup Patel <[email protected]> Signed-off-by: Palmer Dabbelt <[email protected]>
2022-06-01RISC-V: Mark IORESOURCE_EXCLUSIVE for reserved mem instead of IORESOURCE_BUSYXianting Tian1-2/+2
Commit 00ab027a3b82 ("RISC-V: Add kernel image sections to the resource tree") marked IORESOURCE_BUSY for reserved memory, which caused resource map failed in subsequent operations of related driver, so remove the IORESOURCE_BUSY flag. In order to prohibit userland mapping reserved memory, mark IORESOURCE_EXCLUSIVE for it. The code to reproduce the issue, dts: mem0: memory@a0000000 { reg = <0x0 0xa0000000 0 0x1000000>; no-map; }; &test { status = "okay"; memory-region = <&mem0>; }; code: np = of_parse_phandle(pdev->dev.of_node, "memory-region", 0); ret = of_address_to_resource(np, 0, &r); base = devm_ioremap_resource(&pdev->dev, &r); // base = -EBUSY Fixes: 00ab027a3b82 ("RISC-V: Add kernel image sections to the resource tree") Reported-by: Huaming Jiang <[email protected]> Reviewed-by: Guo Ren <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Co-developed-by: Nick Kossifidis <[email protected]> Signed-off-by: Xianting Tian <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2022-06-01riscv: Wire up memfd_secret in UAPI headerTobias Klauser2-1/+1
Move the __ARCH_WANT_MEMFD_SECRET define added in commit 7bb7f2ac24a0 ("arch, mm: wire up memfd_secret system call where relevant") to <uapi/asm/unistd.h> so __NR_memfd_secret is defined when including <unistd.h> in userspace. This allows the memfd_secret selftest to pass on riscv. Signed-off-by: Tobias Klauser <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: 7bb7f2ac24a0 ("arch, mm: wire up memfd_secret system call where relevant") Cc: [email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2022-06-01riscv: Fix irq_work when SMP is disabledSamuel Holland1-1/+1
irq_work is triggered via an IPI, but the IPI infrastructure is not included in uniprocessor kernels. As a result, irq_work never runs. Fall back to the tick-based irq_work implementation on uniprocessor configurations. Fixes: 298447928bb1 ("riscv: Support irq_work via self IPIs") Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2022-06-01riscv: Improve virtual kernel memory layout dumpAlexandre Ghiti1-15/+51
With the arrival of sv48 and its large address space, it would be cumbersome to statically define the unit size to use to print the different portions of the virtual memory layout: instead, determine it dynamically. Signed-off-by: Alexandre Ghiti <[email protected]> Signed-off-by: Palmer Dabbelt <[email protected]>
2022-06-01riscv: Initialize thread pointer before calling C functionsAlexandre Ghiti1-0/+1
Because of the stack canary feature that reads from the current task structure the stack canary value, the thread pointer register "tp" must be set before calling any C function from head.S: by chance, setup_vm and all the functions that it calls does not seem to be part of the functions where the canary check is done, but in the following commits, some functions will. Fixes: f2c9699f65557a31 ("riscv: Add STACKPROTECTOR supported") Signed-off-by: Alexandre Ghiti <[email protected]> Cc: [email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2022-06-01RISC-V: Only default to spinwait on SBI-0.1 and M-modePalmer Dabbelt1-1/+7
The spinwait boot method has been superseded by the SBI HSM extension for some time now, but it still enabled by default. This causes some issues on large hart count systems, which will hang if a physical hart exists that is larger than NR_CPUS. Users on modern SBI implementation don't need spinwait, and while it's probably possible to deal with some of the spinwait issues let's just restrict the default to systems that are likely to actually use it. Signed-off-by: Palmer Dabbelt <[email protected]> Reviewed-by: Atish Patra <[email protected]> Reviewed-by: Anup Patel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2022-06-01x86/kexec: fix memory leak of elf header bufferBaoquan He1-3/+9
This is reported by kmemleak detector: unreferenced object 0xffffc900002a9000 (size 4096): comm "kexec", pid 14950, jiffies 4295110793 (age 373.951s) hex dump (first 32 bytes): 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............ 04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 ..>............. backtrace: [<0000000016a8ef9f>] __vmalloc_node_range+0x101/0x170 [<000000002b66b6c0>] __vmalloc_node+0xb4/0x160 [<00000000ad40107d>] crash_prepare_elf64_headers+0x8e/0xcd0 [<0000000019afff23>] crash_load_segments+0x260/0x470 [<0000000019ebe95c>] bzImage64_load+0x814/0xad0 [<0000000093e16b05>] arch_kexec_kernel_image_load+0x1be/0x2a0 [<000000009ef2fc88>] kimage_file_alloc_init+0x2ec/0x5a0 [<0000000038f5a97a>] __do_sys_kexec_file_load+0x28d/0x530 [<0000000087c19992>] do_syscall_64+0x3b/0x90 [<0000000066e063a4>] entry_SYSCALL_64_after_hwframe+0x44/0xae In crash_prepare_elf64_headers(), a buffer is allocated via vmalloc() to store elf headers. While it's not freed back to system correctly when kdump kernel is reloaded or unloaded. Then memory leak is caused. Fix it by introducing x86 specific function arch_kimage_file_post_load_cleanup(), and freeing the buffer there. And also remove the incorrect elf header buffer freeing code. Before calling arch specific kexec_file loading function, the image instance has been initialized. So 'image->elf_headers' must be NULL. It doesn't make sense to free the elf header buffer in the place. Three different people have reported three bugs about the memory leak on x86_64 inside Redhat. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Baoquan He <[email protected]> Acked-by: Dave Young <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-06-01riscv: dts: icicle: sort nodes alphabeticallyConor Dooley1-52/+52
The icicle device tree is in a "random" order, so clean it up and sort its elements alphabetically to match the newly added PolarBerry dts. Signed-off-by: Conor Dooley <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2022-06-01riscv: microchip: icicle: readability fixesConor Dooley1-3/+5
Fix the sort order of the status properties, remove some extra whitespace in the mmc entry & add whitespace to the mac entry containing the phys so that the dt is easier to read. Signed-off-by: Conor Dooley <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>