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

kbuild: Split .modinfo out from ELF_DETAILS

2026-03-12T11:09:39Z

commit 8678591b47469fe16357234efef9b260317b8be4 upstream. Commit 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") added .modinfo to ELF_DETAILS while removing it from COMMON_DISCARDS, as it was needed in vmlinux.unstripped and ELF_DETAILS was present in all architecture specific vmlinux linker scripts. While this shuffle is fine for vmlinux, ELF_DETAILS and COMMON_DISCARDS may be used by other linker scripts, such as the s390 and x86 compressed boot images, which may not expect to have a .modinfo section. In certain circumstances, this could result in a bootloader failing to load the compressed kernel [1]. Commit ddc6cbef3ef1 ("s390/boot/vmlinux.lds.S: Ensure bzImage ends with SecureBoot trailer") recently addressed this for the s390 bzImage but the same bug remains for arm, parisc, and x86. The presence of .modinfo in the x86 bzImage was the root cause of the issue worked around with commit d50f21091358 ("kbuild: align modinfo section for Secureboot Authenticode EDK2 compat"). misc.c in arch/x86/boot/compressed includes lib/decompress_unzstd.c, which in turn includes lib/xxhash.c and its MODULE_LICENSE / MODULE_DESCRIPTION macros due to the STATIC definition. Split .modinfo out from ELF_DETAILS into its own macro and handle it in all vmlinux linker scripts. Discard .modinfo in the places where it was previously being discarded from being in COMMON_DISCARDS, as it has never been necessary in those uses. Cc: stable@vger.kernel.org Fixes: 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") Reported-by: Ed W Closes: https://lore.kernel.org/587f25e0-a80e-46a5-9f01-87cb40cfa377@wildgooses.com/ [1] Tested-by: Ed W # x86_64 Link: https://patch.msgid.link/20260225-separate-modinfo-from-elf-details-v1-1-387ced6baf4b@kernel.org Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman

riscv: vector: init vector context with proper vlenb

2026-03-04T12:20:35Z

[ Upstream commit ef3ff40346db8476a9ef7269fc9d1837e7243c40 ] The vstate in thread_struct is zeroed when the vector context is initialized. That includes read-only register vlenb, which holds the vector register length in bytes. Zeroed state persists until mstatus.VS becomes 'dirty' and a context switch saves the actual hardware values. This can expose the zero vlenb value to the user-space in early debug scenarios, e.g. when ptrace attaches to a traced process early, before any vector instruction except the first one was executed. Fix this by specifying proper vlenb on vector context init. Signed-off-by: Sergey Matyukevich Reviewed-by: Andy Chiu Tested-by: Andy Chiu Link: https://patch.msgid.link/20251214163537.1054292-3-geomatsi@gmail.com Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin

riscv: signal: fix some warnings reported by sparse

2026-01-26T04:08:53Z

Clean up a few warnings reported by sparse in arch/riscv/kernel/signal.c. These come from code that was added recently; they were missed when I initially reviewed the patch. Fixes: 818d78ba1b3f ("riscv: signal: abstract header saving for setup_sigcontext") Cc: Andy Chiu Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202601171848.ydLTJYrz-lkp@intel.com/ [pjw@kernel.org: updated to apply] Signed-off-by: Paul Walmsley

riscv: suspend: Fix stimecmp update hazard on RV32

2026-01-15T00:43:22Z

On RV32, updating the 64-bit stimecmp (or vstimecmp) CSR requires two separate 32-bit writes. A race condition exists if the timer triggers during these two writes. The RISC-V Privileged Specification (e.g., Section 3.2.1 for mtimecmp) recommends a specific 3-step sequence to avoid spurious interrupts when updating 64-bit comparison registers on 32-bit systems: 1. Set the low-order bits (stimecmp) to all ones (ULONG_MAX). 2. Set the high-order bits (stimecmph) to the desired value. 3. Set the low-order bits (stimecmp) to the desired value. Current implementation writes the LSB first without ensuring a future value, which may lead to a transient state where the 64-bit comparison is incorrectly evaluated as "expired" by the hardware. This results in spurious timer interrupts. This patch adopts the spec-recommended 3-step sequence to ensure the intermediate 64-bit state is never smaller than the current time. Fixes: ffef54ad4110 ("riscv: Add stimecmp save and restore") Signed-off-by: Naohiko Shimizu Reviewed-by: Anup Patel Link: https://patch.msgid.link/20260104135938.524-4-naohiko.shimizu@gmail.com Signed-off-by: Paul Walmsley

riscv: trace: fix snapshot deadlock with sbi ecall

2026-01-07T20:25:56Z

If sbi_ecall.c's functions are traceable, echo "__sbi_ecall:snapshot" > /sys/kernel/tracing/set_ftrace_filter may get the kernel into a deadlock. (Functions in sbi_ecall.c are excluded from tracing if CONFIG_RISCV_ALTERNATIVE_EARLY is set.) __sbi_ecall triggers a snapshot of the ringbuffer. The snapshot code raises an IPI interrupt, which results in another call to __sbi_ecall and another snapshot... All it takes to get into this endless loop is one initial __sbi_ecall. On RISC-V systems without SSTC extension, the clock events in timer-riscv.c issue periodic sbi ecalls, making the problem easy to trigger. Always exclude the sbi_ecall.c functions from tracing to fix the potential deadlock. sbi ecalls can easiliy be logged via trace events, excluding ecall functions from function tracing is not a big limitation. Signed-off-by: Martin Kaiser Link: https://patch.msgid.link/20251223135043.1336524-1-martin@kaiser.cx Signed-off-by: Paul Walmsley

riscv: cpu_ops_sbi: smp_processor_id() returns int, not unsigned int

2026-01-07T20:03:16Z

The print in sbi_cpu_stop() assumes smp_processor_id() returns an unsigned int, when it is actually an int. Fix the format string to avoid mismatch type warnings in rht pr_crit(). Signed-off-by: Ben Dooks Link: https://patch.msgid.link/20260102145839.657864-1-ben.dooks@codethink.co.uk Signed-off-by: Paul Walmsley

riscv: kexec_image: Fix dead link to boot-image-header.rst

2026-01-06T00:54:11Z

Fix the reference to 'boot-image-header.rst', which was moved to 'Documentation/arch/riscv/' in commit 'ed843ae947f8' ("docs: move riscv under arch"). Signed-off-by: Soham Metha Link: https://patch.msgid.link/20251203194355.63265-1-sohammetha01@gmail.com Signed-off-by: Paul Walmsley

riscv: cpufeature: Fix Zk bundled extension missing Zknh

2026-01-06T00:40:44Z

The Zk extension is a bundle consisting of Zkn, Zkr, and Zkt. The Zkn extension itself is a bundle consisting of Zbkb, Zbkc, Zbkx, Zknd, Zkne, and Zknh. The current implementation of riscv_zk_bundled_exts manually listed the dependencies but missed RISCV_ISA_EXT_ZKNH. Fix this by introducing a RISCV_ISA_EXT_ZKN macro that lists the Zkn components and using it in both riscv_zk_bundled_exts and riscv_zkn_bundled_exts. This adds the missing Zknh extension to Zk and reduces code duplication. Fixes: 0d8295ed975b ("riscv: add ISA extension parsing for scalar crypto") Link: https://patch.msgid.link/20231114141256.126749-4-cleger@rivosinc.com/ Signed-off-by: Guodong Xu Reviewed-by: Clément Léger Link: https://patch.msgid.link/20251223-zk-missing-zknh-v1-1-b627c990ee1a@riscstar.com Signed-off-by: Paul Walmsley

riscv: fix KUnit test_kprobes crash when building with Clang

2025-12-31T03:10:52Z

Clang misinterprets the placement of test_kprobes_addresses and test_kprobes_functions arrays when they are not explicitly assigned to a data section. This can lead to kmalloc_array() allocation errors and KUnit failures. When testing the Clang-compiled code in QEMU, this warning was emitted: WARNING: CPU: 1 PID: 3000 at mm/page_alloc.c:5159 __alloc_frozen_pages_noprof+0xe6/0x2fc mm/page_alloc.c:5159 Further investigation revealed that the test_kprobes_addresses array appeared to have over 100,000 elements, including invalid addresses; whereas, according to test-kprobes-asm.S, test_kprobes_addresses should only have 25 elements. When compiling the kernel with GCC, the kernel boots correctly. This patch fixes the issue by adding .section .rodata to explicitly place arrays in the read-only data segment. For detailed debug and analysis, see: https://github.com/j1akai/temp/blob/main/20251113/readme.md v1 -> v2： - Drop changes to .align, and .globl. Signed-off-by: Jiakai Xu Signed-off-by: Jiakai Xu Link: https://patch.msgid.link/738dd4e2.ff73.19a7cd7b4d5.Coremail.xujiakai2025@iscas.ac.cn Link: https://github.com/llvm/llvm-project/issues/168308 Link: https://patch.msgid.link/20251226032317.1523764-1-jiakaiPeanut@gmail.com Signed-off-by: Paul Walmsley

riscv: Sanitize syscall table indexing under speculation

2025-12-31T02:57:55Z

The syscall number is a user-controlled value used to index into the syscall table. Use array_index_nospec() to clamp this value after the bounds check to prevent speculative out-of-bounds access and subsequent data leakage via cache side channels. Signed-off-by: Lukas Gerlach Link: https://patch.msgid.link/20251218191332.35849-3-lukas.gerlach@cispa.de Signed-off-by: Paul Walmsley