kernel.git/arch/riscv/kernel, branch linux-6.4.y

riscv: Handle zicsr/zifencei issue between gcc and binutils

2023-08-30T12:52:41Z

commit ca09f772cccaeec4cd05a21528c37a260aa2dd2c upstream. Binutils-2.38 and GCC-12.1.0 bumped[0][1] the default ISA spec to the newer 20191213 version which moves some instructions from the I extension to the Zicsr and Zifencei extensions. So if one of the binutils and GCC exceeds that version, we should explicitly specifying Zicsr and Zifencei via -march to cope with the new changes. but this only occurs when binutils >= 2.36 and GCC >= 11.1.0. It's a different story when binutils < 2.36. binutils-2.36 supports the Zifencei extension[2] and splits Zifencei and Zicsr from I[3]. GCC-11.1.0 is particular[4] because it add support Zicsr and Zifencei extension for -march. binutils-2.35 does not support the Zifencei extension, and does not need to specify Zicsr and Zifencei when working with GCC >= 12.1.0. To make our lives easier, let's relax the check to binutils >= 2.36 in CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI. For the other two cases, where clang < 17 or GCC < 11.1.0, we will deal with them in CONFIG_TOOLCHAIN_NEEDS_OLD_ISA_SPEC. For more information, please refer to: commit 6df2a016c0c8 ("riscv: fix build with binutils 2.38") commit e89c2e815e76 ("riscv: Handle zicsr/zifencei issues between clang and binutils") Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aed44286efa8ae8717a77d94b51ac3614e2ca6dc [0] Link: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98416dbb0a62579d4a7a4a76bab51b5b52fec2cd [1] Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=5a1b31e1e1cee6e9f1c92abff59cdcfff0dddf30 [2] Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=729a53530e86972d1143553a415db34e6e01d5d2 [3] Link: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b03be74bad08c382da47e048007a78fa3fb4ef49 [4] Link: https://lore.kernel.org/all/20230308220842.1231003-1-conor@kernel.org Link: https://lore.kernel.org/all/20230223220546.52879-1-conor@kernel.org Reviewed-by: Conor Dooley Acked-by: Guo Ren Cc: Signed-off-by: Mingzheng Xing Link: https://lore.kernel.org/r/20230809165648.21071-1-xingmingzheng@iscas.ac.cn Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman

riscv: entry: set a0 = -ENOSYS only when syscall != -1

2023-08-23T15:32:51Z

[ Upstream commit 52449c17bdd1540940e21511612b58acebc49c06 ] When we test seccomp with 6.4 kernel, we found errno has wrong value. If we deny NETLINK_AUDIT with EAFNOSUPPORT, after f0bddf50586d, we will get ENOSYS instead. We got same result with commit 9c2598d43510 ("riscv: entry: Save a0 prior syscall_enter_from_user_mode()"). After analysing code, we think that regs->a0 = -ENOSYS should only be executed when syscall != -1. In __seccomp_filter, when seccomp rejected this syscall with specified errno, they will set a0 to return number as syscall ABI, and then return -1. This return number is finally pass as return number of syscall_enter_from_user_mode, and then is compared with NR_syscalls after converted to ulong (so it will be ULONG_MAX). The condition syscall < NR_syscalls will always be false, so regs->a0 = -ENOSYS is always executed. It covered a0 set by seccomp, so we always get ENOSYS when match seccomp RET_ERRNO rule. Fixes: f0bddf50586d ("riscv: entry: Convert to generic entry") Reported-by: Felix Yan Co-developed-by: Ruizhe Pan Signed-off-by: Ruizhe Pan Co-developed-by: Shiqi Zhang Signed-off-by: Shiqi Zhang Signed-off-by: Celeste Liu Tested-by: Felix Yan Tested-by: Emil Renner Berthing Reviewed-by: Björn Töpel Reviewed-by: Guo Ren Link: https://lore.kernel.org/r/20230801141607.435192-1-CoelacanthusHex@gmail.com Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin

riscv/kexec: handle R_RISCV_CALL_PLT relocation type

2023-08-16T16:32:18Z

commit d0b4f95a51038becce4bdab4789aa7ce59d4ea6e upstream. R_RISCV_CALL has been deprecated and replaced by R_RISCV_CALL_PLT. See Enum 18-19 in Table 3. Relocation types here: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc It was deprecated in ("Deprecated R_RISCV_CALL, prefer R_RISCV_CALL_PLT"): https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/a0dced85018d7a0ec17023c9389cbd70b1dbc1b0 Recent tools (at least GNU binutils-2.40) already use R_RISCV_CALL_PLT. Kernels built with such binutils fail kexec_load_file(2) with: kexec_image: Unknown rela relocation: 19 kexec_image: Error loading purgatory ret=-8 The binary code at the call site remains the same, so tell arch_kexec_apply_relocations_add() to handle _PLT alike. Fixes: 838b3e28488f ("RISC-V: Load purgatory in kexec_file") Signed-off-by: Torsten Duwe Signed-off-by: Petr Tesarik Cc: Li Zhengyu Cc: stable@vger.kernel.org Reviewed-by: Conor Dooley Link: https://lore.kernel.org/all/b046b164af8efd33bbdb7d4003273bdf9196a5b0.1690365011.git.petr.tesarik.ext@huawei.com/ Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman

riscv/kexec: load initrd high in available memory

2023-08-16T16:32:18Z

commit 49af7a2cd5f678217b8b4f86a29411aebebf3e78 upstream. When initrd is loaded low, the secondary kernel fails like this: INITRD: 0xdc581000+0x00eef000 overlaps in-use memory region This initrd load address corresponds to the _end symbol, but the reservation is aligned on PMD_SIZE, as explained by a comment in setup_bootmem(). It is technically possible to align the initrd load address accordingly, leaving a hole between the end of kernel and the initrd, but it is much simpler to allocate the initrd top-down. Fixes: 838b3e28488f ("RISC-V: Load purgatory in kexec_file") Signed-off-by: Torsten Duwe Signed-off-by: Petr Tesarik Cc: stable@vger.kernel.org Reviewed-by: Conor Dooley Link: https://lore.kernel.org/all/67c8eb9eea25717c2c8208d9bfbfaa39e6e2a1c6.1690365011.git.petr.tesarik.ext@huawei.com/ Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman

riscv: Export va_kernel_pa_offset in vmcoreinfo

2023-08-11T10:14:20Z

commit fbe7d19d2b7fcbd38905ba9f691be8f245c6faa6 upstream. Since RISC-V Linux v6.4, the commit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping") changes phys_ram_base from the physical start of the kernel to the actual start of the DRAM. The Crash-utility's VTOP() still uses phys_ram_base and kernel_map.virt_addr to translate kernel virtual address, that failed the Crash with Linux v6.4 [1]. Export kernel_map.va_kernel_pa_offset in vmcoreinfo to help Crash translate the kernel virtual address correctly. Fixes: 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping") Link: https://lore.kernel.org/linux-riscv/20230724040649.220279-1-suagrfillet@gmail.com/ [1] Signed-off-by: Song Shuai Reviewed-by: Xianting Tian Reviewed-by: Alexandre Ghiti Link: https://lore.kernel.org/r/20230724100917.309061-1-suagrfillet@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman

risc-v: Fix order of IPI enablement vs RCU startup

2023-07-19T14:36:49Z

[ Upstream commit 6259f3443c6a376aa077816ac92e9ddeb0817d09 ] Conor reports that risc-v tries to enable IPIs before telling the core code to enable RCU. With the introduction of the mapple tree as a backing store for the irq descriptors, this results in a very shouty boot sequence, as RCU is legitimately upset. Restore some sanity by moving the risc_ipi_enable() call after notify_cpu_starting(), which explicitly enables RCU on the calling CPU. Fixes: 832f15f42646 ("RISC-V: Treat IPIs as normal Linux IRQs") Reported-by: Conor Dooley Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20230703-dupe-frying-79ae2ccf94eb@spud Cc: Anup Patel Cc: Palmer Dabbelt Cc: Linus Torvalds Tested-by: Conor Dooley Link: https://lore.kernel.org/r/20230703183126.1567625-1-maz@kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin

riscv: hibernate: remove WARN_ON in save_processor_state

2023-07-19T14:36:17Z

[ Upstream commit 91afbaafd6b1f1846520efd2b158066a25a1a316 ] During hibernation or restoration, freeze_secondary_cpus checks num_online_cpus via BUG_ON, and the subsequent save_processor_state also does the checking with WARN_ON. In the case of CONFIG_PM_SLEEP_SMP=n, freeze_secondary_cpus is not defined, but the sole possible condition to disable CONFIG_PM_SLEEP_SMP is !SMP where num_online_cpus is always 1. We also don't have to check it in save_processor_state. So remove the unnecessary checking in save_processor_state. Fixes: c0317210012e ("RISC-V: Add arch functions to support hibernation/suspend-to-disk") Signed-off-by: Song Shuai Reviewed-by: Conor Dooley Link: https://lore.kernel.org/r/20230609075049.2651723-4-songshuaishuai@tinylab.org Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin

riscv: uprobes: Restore thread.bad_cause

2023-07-19T14:36:16Z

[ Upstream commit 58b1294dd1d65bb62f08dddbf418f954210c2057 ] thread.bad_cause is saved in arch_uprobe_pre_xol(), it should be restored in arch_uprobe_{post,abort}_xol() accordingly, otherwise the save operation is meaningless, this change is similar with x86 and powerpc. Signed-off-by: Tiezhu Yang Acked-by: Oleg Nesterov Reviewed-by: Guo Ren Fixes: 74784081aac8 ("riscv: Add uprobes supported") Link: https://lore.kernel.org/r/1682214146-3756-1-git-send-email-yangtiezhu@loongson.cn Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin

riscv: hibernation: Remove duplicate call of suspend_restore_csrs

2023-07-19T14:36:16Z

[ Upstream commit c6399b893043a5bb634de8677362f96684f1c0c8 ] The suspend_restore_csrs is called in both __hibernate_cpu_resume and the `else` of subsequent swsusp_arch_suspend. Removing the first call makes both suspend_{save,restore}_csrs left in swsusp_arch_suspend for clean code. Fixes: c0317210012e ("RISC-V: Add arch functions to support hibernation/suspend-to-disk") Reviewed-by: Conor Dooley Reviewed-by: JeeHeng Sia Signed-off-by: Song Shuai Link: https://lore.kernel.org/r/20230522025020.285042-1-songshuaishuai@tinylab.org Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin

Merge tag 'riscv-for-linus-6.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux

2023-06-02T17:47:36Z

Pull RISC-V fixes from Palmer Dabbelt: - A build warning fix for BUILTIN_DTB=y - Hibernation support is hidden behind NONPORTABLE, as it depends on some undocumented early boot behavior and breaks on most platforms - A fix for relocatable kernels on systems with early boot errata - A fix to properly handle perf callchains for kernel tracepoints - A pair of fixes for NAPOT to avoid inconsistencies between PTEs and handle hardware that sets arbitrary A/D bits * tag 'riscv-for-linus-6.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: Implement missing huge_ptep_get riscv: Fix huge_ptep_set_wrprotect when PTE is a NAPOT riscv: perf: Fix callchain parse error with kernel tracepoint events riscv: Fix relocatable kernels with early alternatives using -fno-pie RISC-V: mark hibernation as nonportable riscv: Fix unused variable warning when BUILTIN_DTB is set