kernel/git/stable/linux.git/arch/riscv, branch linux-rolling-stable

bpf, riscv: Make arena support depend on ZACAS

2026-09-11T09:50:52+00:00

commit 536b523b407397c8d3967c020ce7aad70a0ea030 upstream. The arena range tree allocates its nodes with kmalloc_nolock() since commit f8c67d8550ee ("bpf: Use kmalloc_nolock() in range tree"). kmalloc_nolock() requires slab caches with cmpxchg128 support (__CMPXCHG_DOUBLE); on riscv cmpxchg128 is provided by the ZACAS extension. On systems without ZACAS every arena map creation fails with a misleading -ENOMEM. Report the missing support instead: make bpf_jit_supports_arena() return system_has_cmpxchg128() where it is defined, so arena map creation fails with -EOPNOTSUPP on systems without ZACAS. The macro is only defined when both CONFIG_RISCV_ISA_ZACAS and CONFIG_TOOLCHAIN_HAS_ZACAS are enabled, so guard it with #ifdef the same way mm/slab.h consumes it, and reject arena otherwise. This matches how arena BPF_CMPXCHG instructions are already gated on ZACAS in bpf_jit_supports_insn(). Fixes: f8c67d8550ee ("bpf: Use kmalloc_nolock() in range tree") Signed-off-by: Chen Pei Acked-by: Pu Lehui Acked-by: Björn Töpel Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20260902061451.1416-1-cp0613@linux.alibaba.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Greg Kroah-Hartman

riscv: unaligned: stop using kthread for check_vector_unaligned_access()

2026-09-07T15:37:05+00:00

commit 34c9cfcde29b938c416924ee6ec3519270bc2238 upstream. A kthread is used to run check_vector_unaligned_access() to optimize boot time, allowing the kernel to continue booting without waiting for the unaligned vector speed probe to finish. However, this asynchronous approach introduces several complications. First, the kthread may not complete before a user reads vDSO data, resulting in incorrect values. This was previously addressed by commit 5d15d2ad36b0 ("riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot"), which added complex synchronization between the kthread and vDSO reads. Second, it was discovered that the kthread may not finish before vec_check_unaligned_access_speed_all_cpus() (marked with __init) is freed, triggering a page fault. These issues raise the question of whether the kthread is worth the added complexity. A past boot time regression report was actually unrelated to synchronous probing; it was caused by the probe running serially. Since switching to a parallel probe, no further complaints have been made. Furthermore, the unaligned scalar access speed probe takes the same amount of time, runs synchronously, and has caused no issues. Testing shows no noticeable boot time slowdown when running the vector probe synchronously (0.464474s with kthread vs. 0.457991s without). Remove the kthread usage and run the probe synchronously. This simplifies the boot flow and allows for the revert of commit 5d15d2ad36b0 ("riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot") Reported-by: Anirudh Srinivasan Closes: https://lore.kernel.org/linux-riscv/20260612-vec_unaligned_drop_init-v1-1-df969210ae34@oss.tenstorrent.com/ Fixes: e7c9d66e313b ("RISC-V: Report vector unaligned access speed hwprobe") Cc: stable@vger.kernel.org Signed-off-by: Nam Cao Acked-by: Jesse Taube Tested-by: Anirudh Srinivasan Link: https://patch.msgid.link/1c378963f27c5960e8a57c50b8b444d30954cb54.1781666867.git.namcao@linutronix.de [pjw@kernel.org: updated to apply; adjusted Fixes: tag; fixed my own manual patch application error] Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman

riscv: acpi: Handle LPI architectural context loss flags

2026-09-07T15:37:05+00:00

commit 7e4cb63d61a7e0bef20f0d00e831c7fac06e4a1c upstream. Commit 4785aa802853 ("cpuidle, ACPI: Evaluate LPI arch_flags for broadcast timer") replaced the generic nonzero check for LPI architectural context loss flags with arch_get_idle_state_flags(). RISC-V does not implement the helper, so it falls back to the stub that returns 0. Consequently, CPUIDLE_FLAG_TIMER_STOP is not set when an LPI state loses the hart timer context, preventing cpuidle from using a broadcast timer for that state. Implement the RISC-V helper and map the hart timer context loss flag to CPUIDLE_FLAG_TIMER_STOP. Fixes: 4785aa802853 ("cpuidle, ACPI: Evaluate LPI arch_flags for broadcast timer") Cc: stable@vger.kernel.org Acked-by: Sudeep Holla Reviewed-by: Yixun Lan Reviewed-by: Sunil V L Reviewed-by: Huisong Li Signed-off-by: Peixin Xie Link: https://patch.msgid.link/20260803-riscv-acpi-lpi-timer-v3-1-520fa13732f5@linux.spacemit.com Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman

RISC-V: KVM: Fix PMU event info array size overflow

2026-09-07T15:37:05+00:00

commit 735bc20c24187ca419c9d5e63860a54b91be34bd upstream. SBI PMU EVENT_GET_INFO stores guest-controlled num_events * sizeof(*einfo) in a 32-bit integer. On RV64, num_events = 0x10000001 makes 0x100000010 truncate to 16. KVM then allocates one entry but loops over the original num_events, causing out-of-bounds reads and writes. A nested guest triggered: BUG: KASAN: slab-out-of-bounds in kvm_riscv_vcpu_pmu_event_info+0xa4/0x142 Read of size 4 at addr ff600000074d46b0 by task init/1 Call Trace: [] kvm_riscv_vcpu_pmu_event_info+0xa4/0x142 [] kvm_sbi_ext_pmu_handler+0xca/0x268 [] kvm_riscv_vcpu_sbi_ecall+0xec/0x1e6 [] kvm_riscv_vcpu_exit+0x48c/0x540 [] kvm_arch_vcpu_ioctl_run+0x37e/0xc80 Allocated by task 1: __kmalloc_noprof+0x19e/0x4b0 kvm_riscv_vcpu_pmu_event_info+0x72/0x142 kvm_sbi_ext_pmu_handler+0xca/0x268 kvm_riscv_vcpu_sbi_ecall+0xec/0x1e6 kvm_riscv_vcpu_exit+0x48c/0x540 kvm_arch_vcpu_ioctl_run+0x37e/0xc80 The buggy address is located 0 bytes to the right of allocated 16-byte region [ff600000074d46a0, ff600000074d46b0) Store the shared-memory size in size_t and reject multiplication overflow. Allocate the guest-driven array with GFP_KERNEL_ACCOUNT so it is charged to kmemcg, and use __GFP_NOWARN to suppress allocation failure warnings. Use kvcalloc() to allow vmalloc fallback and an unsigned long loop index to match num_events. Reported-by: Naveed Khan Closes: https://lore.kernel.org/kvm/178345245327.72065.13249716450708539854@digiscrypt.com/ Fixes: e309fd113b9f ("RISC-V: KVM: Implement get event info function") Cc: stable@vger.kernel.org Signed-off-by: Guidong Han <2045gemini@gmail.com> Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260730092533.1369531-1-2045gemini@gmail.com Signed-off-by: Anup Patel Signed-off-by: Greg Kroah-Hartman

riscv: dts: spacemit: k1-orangepi-rv2: fix maximum CPU core voltage

2026-09-07T15:37:05+00:00

commit ae0c38f0a24f95c8759b6b0eaaa5a0d36a7c6af2 upstream. On the OrangePi RV2 board, the buck1 and buck2 voltage regulators, which supply the CPU core voltage, are configured with a maximum output voltage of 3.45V, while the highest operating point requires only 1.050V. This means that a kernel bug, OPP misconfiguration, or privileged userspace could request a voltage above the safe operating limit, causing possible permanent CPU damage. Set the maximum regulator voltage to 1.050V instead. Fixes: c02c047b925c ("riscv: dts: spacemit: Define the P1 PMIC regulators for OrangePi RV2") Link: https://sashiko.dev/#/message/20260728211020.1248676-2-aurelien%40aurel32.net Cc: stable@vger.kernel.org Signed-off-by: Aurelien Jarno Reviewed-by: Yixun Lan Link: https://patch.msgid.link/20260729150722.1598630-4-aurelien@aurel32.net Signed-off-by: Yixun Lan Signed-off-by: Greg Kroah-Hartman

riscv: dts: spacemit: k1-orangepi-r2s: fix maximum CPU core voltage

2026-09-07T15:37:05+00:00

commit d66267c35032c46c18b675601d03c80239bcd913 upstream. On the OrangePi R2S board, the buck1 and buck2 voltage regulators, which supply the CPU core voltage, are configured with a maximum output voltage of 3.45V, while the highest operating point requires only 1.050V. This means that a kernel bug, OPP misconfiguration, or privileged userspace could request a voltage above the safe operating limit, causing possible permanent CPU damage. Set the maximum regulator voltage to 1.050V instead. Fixes: 793cc54475b4 ("riscv: dts: spacemit: enable PMIC on OrangePi R2S") Link: https://sashiko.dev/#/message/20260728211020.1248676-2-aurelien%40aurel32.net Cc: stable@vger.kernel.org Signed-off-by: Aurelien Jarno Reviewed-by: Yixun Lan Link: https://patch.msgid.link/20260729150722.1598630-6-aurelien@aurel32.net Signed-off-by: Yixun Lan Signed-off-by: Greg Kroah-Hartman

riscv: dts: spacemit: k1-musepi-pro: fix maximum CPU core voltage

2026-09-07T15:37:05+00:00

commit f045253a03589b2616332560b4120e584342a987 upstream. On the MusePi Pro board, the buck1 and buck2 voltage regulators, which supply the CPU core voltage, are configured with a maximum output voltage of 3.45V, while the highest operating point requires only 1.050V. This means that a kernel bug, OPP misconfiguration, or privileged userspace could request a voltage above the safe operating limit, causing possible permanent CPU damage. Set the maximum regulator voltage to 1.050V instead. Fixes: e2dac7c7a3a8 ("riscv: dts: spacemit: k1-musepi-pro: add PMIC and power infrastructure") Link: https://sashiko.dev/#/message/20260728211020.1248676-2-aurelien%40aurel32.net Cc: stable@vger.kernel.org Signed-off-by: Aurelien Jarno Reviewed-by: Yixun Lan Link: https://patch.msgid.link/20260729150722.1598630-5-aurelien@aurel32.net Signed-off-by: Yixun Lan Signed-off-by: Greg Kroah-Hartman

riscv: dts: spacemit: k1-milkv-jupiter: fix maximum CPU core voltage

2026-09-07T15:37:05+00:00

commit 56a77ddae794ca0516fc146f6e59bb8cdf4fd9d2 upstream. On the Milk-V Jupiter board, the buck1 and buck2 voltage regulators, which supply the CPU core voltage, are configured with a maximum output voltage of 3.45V, while the highest operating point requires only 1.050V. This means that a kernel bug, OPP misconfiguration, or privileged userspace could request a voltage above the safe operating limit, causing possible permanent CPU damage. Set the maximum regulator voltage to 1.050V instead. Fixes: 7d307daa12b1 ("riscv: dts: spacemit: Define the P1 PMIC regulators for Milk-V Jupiter") Link: https://sashiko.dev/#/message/20260728211020.1248676-2-aurelien%40aurel32.net Cc: stable@vger.kernel.org Signed-off-by: Aurelien Jarno Reviewed-by: Yixun Lan Link: https://patch.msgid.link/20260729150722.1598630-3-aurelien@aurel32.net Signed-off-by: Yixun Lan Signed-off-by: Greg Kroah-Hartman

riscv: dts: spacemit: k1-bananapi-f3: fix maximum CPU core voltage

2026-09-07T15:37:05+00:00

commit b496282ee4ad07311a13489e15b74fb7078d9a01 upstream. On the Banana Pi BPI-F3 board, the buck1 and buck2 voltage regulators, which supply the CPU core voltage, are configured with a maximum output voltage of 3.45V, while the highest operating point requires only 1.050V. This means that a kernel bug, OPP misconfiguration, or privileged userspace could request a voltage above the safe operating limit, causing possible permanent CPU damage. Set the maximum regulator voltage to 1.050V instead. Fixes: 09a412d39748 ("riscv: dts: spacemit: define regulator constraints") Link: https://sashiko.dev/#/message/20260728211020.1248676-2-aurelien%40aurel32.net Cc: stable@vger.kernel.org Signed-off-by: Aurelien Jarno Reviewed-by: Yixun Lan Link: https://patch.msgid.link/20260729150722.1598630-2-aurelien@aurel32.net Signed-off-by: Yixun Lan Signed-off-by: Greg Kroah-Hartman

riscv: lib: Fix ZBB strnlen reading past count boundary

2026-08-08T17:45:33+00:00

The ZBB-optimized strnlen loop loads one word ahead before checking the aligned boundary: REG_L t1, SZREG(t0) // load next word addi t0, t0, SZREG // advance orc.b t1, t1 bgeu t0, t4, 4f // boundary check AFTER load where t4 = (s + count) & -SZREG. When s is aligned and count is a multiple of SZREG, t4 equals s + count and the loop loads a full word starting at exactly s + count. If s + count falls on a page boundary with the next page unmapped, this faults. Fix by computing the aligned boundary from the last valid byte (s + count - 1) instead of s + count. This makes the loop stop at the word containing the last valid byte rather than potentially loading the word after it. The count == 0 case is already handled by the beqz early exit. Also add a pre-loop guard (bgeu t0, t4) for the case where all valid bytes fit within the first word. With the adjusted boundary, t4 can equal t0, and entering the loop with stale register state from the first-word processing would produce incorrect results. The final minu clamp ensures the result is still correct when the last loaded word extends past s + count - 1 within the same aligned word. Fixes: 5ba15d419fab ("riscv: lib: add strnlen() implementation") Signed-off-by: Michael Neuling Assisted-by: Claude Opus4.6 High Thinking Link: https://patch.msgid.link/20260413010738.1622423-1-mikey@neuling.org Signed-off-by: Paul Walmsley