kernel/git/stable/linux.git/arch/riscv, branch master

riscv: defconfig: enable ARCH_ULTRARISC

2026-07-08T16:41:40+00:00

Enable `ARCH_ULTRARISC` in the default RISC-V defconfig. Signed-off-by: Jia Wang Link: https://patch.msgid.link/20260515-ultrarisc-pinctrl-v1-9-bf559589ea8a@ultrarisc.com Signed-off-by: Paul Walmsley

riscv: add UltraRISC SoC family Kconfig support

2026-07-08T16:39:49+00:00

The first SoC in the UltraRISC series is UR-DP1000, containing octa UltraRISC CP100 cores. Signed-off-by: Jia Wang Acked-by: Conor Dooley Link: https://patch.msgid.link/20260427-ultrarisc-pcie-v4-1-98935f6cdfb5@ultrarisc.com Signed-off-by: Paul Walmsley

riscv: Prevent NULL pointer dereference in machine_kexec_prepare()

2026-07-07T00:24:06+00:00

A NULL pointer dereference issue is noticed in riscv's machine_kexec_prepare(), where image->segment[i].buf might be NULL and copied unchecked. The NULL buf comes from ima_add_kexec_buffer(), where kbuf is added by kexec_add_buffer(), but kbuf.buffer is NULL, then it is copied without a check in machine_kexec_prepare(): kexec_file_load -> kimage_file_alloc_init() -> kimage_file_prepare_segments() -> ima_add_kexec_buffer() -> kexec_add_buffer() -> machine_kexec_prepare() -> memcpy() Address this by adding a check before the data copy attempt. Fixes: b7fb4d78a6ad ("RISC-V: use memcpy for kexec_file mode") Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/kexec/CAO7dBbVftLUhd2qrh7hmijTB3PEPfZAhykCGqEfrPoOcSrrj-w@mail.gmail.com/ Acked-by: Baoquan He Acked-by: Pratyush Yadav Reviewed-by: Nutty Liu Signed-off-by: Tao Liu Link: https://patch.msgid.link/20260705232706.30265-2-ltao@redhat.com Signed-off-by: Paul Walmsley

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

2026-07-04T01:07:24+00:00

Pull RISC-V fixes from Paul Walmsley: - Fix a crash when a kretprobe reads from the stack - Fix an issue with the build-time mcount sorter that broke ftrace - Fix the rv32 IRQ stack frame padding to match the ABI - Only defer IOMMU configuration during initialization. This avoids an issue where IOMMU configuration could be indefinitely deferred - Add the missing build salt to the vDSO - Now that RISC-V systems with higher numbers of cores are starting to become available, raise NR_CPUS for RISC-V to 256 - Clean up some warnings from sparse caused by the RISC-V-optimized RAID6 code - Clean up our __cpu_up() code with a few minor fixes * tag 'riscv-for-linus-7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: probes: save original sp in rethook trampoline riscv: Fix 32-bit call_on_irq_stack() frame pointer ABI scripts/sorttable: Handle RISC-V patchable ftrace entries riscv: smp: use secs_to_jiffies in __cpu_up ACPI: RIMT: Only defer the IOMMU configuration in init stage riscv: Add build salt to the vDSO raid6: fix raid6_recov_rvv symbol undeclared warning raid6: fix riscv symbol undeclared warnigns riscv: Raise default NR_CPUS for 64BIT to 256

bpf: Restrict JIT predictor flush to cBPF

2026-07-01T08:33:38+00:00

Currently predictor flush on memory reuse is done for all BPF JIT allocations, but only cBPF programs can be loaded by an unprivileged user. eBPF is privileged by default, and flushing predictors for all CPUs on every eBPF reuse penalizes the common case for no security benefit. eBPF allocations can be frequent on busy systems, only flush predictors for cBPF programs. Trampoline and dispatcher allocations also skip the flush as they are eBPF-only. Signed-off-by: Pawan Gupta Acked-by: Daniel Borkmann Signed-off-by: Daniel Borkmann

riscv: probes: save original sp in rethook trampoline

2026-07-01T00:46:54+00:00

Reading a word from the stack in a kretprobe crashes a risc-v kernel. $ cd /sys/kernel/tracing/ $ echo 'r n_tty_write $stack0' > dynamic_events $ echo 1 > events/kprobes/enable Unable to handle kernel paging request at virtual address 0000000200000128 ... [] regs_get_kernel_stack_nth+0x26/0x38 [] process_fetch_insn+0x3ee/0x760 [] kretprobe_trace_func+0x116/0x1f0 [] kretprobe_dispatcher+0x4a/0x58 [] kretprobe_rethook_handler+0x5e/0x90 [] rethook_trampoline_handler+0x70/0x108 [] arch_rethook_trampoline_callback+0x12/0x1c [] arch_rethook_trampoline+0x48/0x94 [] tty_write+0x1a/0x30 In regs_get_kernel_stack_nth, regs->sp contains an arbitrary value. arch_rethook_trampoline saves the registers from the probed function in a struct pt_regs. sp is not saved. Instead, sp is decremented for arch_rethook_trampoline's local stack. Fix this crash and save the original sp along with the other registers. Use a0 as a temporary register, it is overwritten anyway. Cc: stable@vger.kernel.org Fixes: c22b0bcb1dd02 ("riscv: Add kprobes supported") Signed-off-by: Martin Kaiser Acked-by: Masami Hiramatsu (Google) Link: https://patch.msgid.link/20260630194010.1824039-1-martin@kaiser.cx [pjw@kernel.org: added Fixes tag; cc'ed stable] Signed-off-by: Paul Walmsley

riscv: Fix 32-bit call_on_irq_stack() frame pointer ABI

2026-06-25T19:44:27+00:00

call_on_irq_stack() uses struct member offsets to set up its link in the frame record list. On riscv32, struct stackframe is the wrong size to maintain stack pointer alignment, so STACKFRAME_SIZE_ON_STACK includes padding. However, the ABI requires the frame record to be placed immediately below the address stored in s0, so the padding must come before the struct members. Fix the layout by making STACKFRAME_FP and STACKFRAME_RA the negative offsets from s0, instead of the positive offsets from sp. Fixes: 82982fdd5133 ("riscv: Deduplicate IRQ stack switching") Signed-off-by: Samuel Holland Reviewed-by: Matthew Bystrin Signed-off-by: Rui Qi Link: https://lore.kernel.org/all/20240530001733.1407654-2-samuel.holland@sifive.com/ Reviewed-by: Nam Cao Link: https://patch.msgid.link/20260624113148.3723541-1-qirui.001@bytedance.com [pjw@kernel.org: cleaned up the patch tags and added Matthew's Reviewed-by] Signed-off-by: Paul Walmsley

riscv: smp: use secs_to_jiffies in __cpu_up

2026-06-25T18:24:25+00:00

Use secs_to_jiffies() to simplify the code. Drop the redundant zero initialization while at it. Signed-off-by: Thorsten Blum Link: https://patch.msgid.link/20260611232537.467398-3-thorsten.blum@linux.dev Signed-off-by: Paul Walmsley

riscv: Add build salt to the vDSO

2026-06-25T18:05:05+00:00

The vDSO needs to have a unique build id in a similar manner to the kernel and modules. Use the build salt macro. Signed-off-by: Bastian Blank Reviewed-by: Nam Cao Link: https://patch.msgid.link/ajQY7n0an0YwQ--j@steamhammer.waldi.eu.org Signed-off-by: Paul Walmsley

riscv: Raise default NR_CPUS for 64BIT to 256

2026-06-25T17:41:15+00:00

SpacemiT has already produced a 80-core RVA23 RISC-V server [1], and going further back, the dual-socket SG2042-based Sophgo Pisces has 128 cores (although that had some issues achieving mainline support). Therefore, an NR_CPUS of 64 is not enough. Raise default NR_CPUS to 256 for 64BIT (when !RISCV_SBI_V01, since very old firmware can't support more than 64 cores). The number was picked as a power of two that is at least double the known max. I believe this should be the right balance between not wasting too much memory and not having to touch this too often. Ubuntu has already been shipping NR_CPUS=512 for riscv64. We have also been testing NR_CPUS=256 internally at ISCAS and found negligible performance impact and no ill effects. Reported-by: Lufei Zheng Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1140651 # [1] Suggested-by: Han Gao Signed-off-by: Vivian Wang Link: https://patch.msgid.link/20260625-riscv-more-nr-cpus-v1-1-5da8c72b9269@iscas.ac.cn Signed-off-by: Paul Walmsley