summaryrefslogtreecommitdiff
path: root/arch/riscv
AgeCommit message (Collapse)Author
12 daysbpf, riscv: Fix extable handling for arena load_acquireFeng Jiang
emit_atomic_ld_st() returns 1 to have build_body() skip the zext after a sub-word load_acquire. The caller does "ret = ret ?: add_exception_handler(...)", which skips add_exception_handler() on any non-zero ret, so the extable entry is missing and a faulting PROBE_ATOMIC load_acquire oopses. REG_DONT_CLEAR_MARKER leaves rd stale on fault, and the verifier still thinks the load overwrote it, so a program can leak it through a map. Check ret >= 0 before calling add_exception_handler(), and pass rd for LOAD_ACQ so the fault zeroes rd like a PROBE_MEM load. Return ret unchanged for the zext skip. Fixes: fb7cefabae81 ("riscv, bpf: Add support arena atomics for RV64") Suggested-by: Pu Lehui <pulehui@huawei.com> Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn> Reviewed-by: Pu Lehui <pulehui@huawei.com> Reviewed-by: Björn Töpel <bjorn@kernel.org> Acked-by: Björn Töpel <bjorn@kernel.org> Link: https://lore.kernel.org/bpf/20260720-bpf-riscv-fix-extable-v4-1-165c0b3b07d5@kylinos.cn Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
12 daysriscv, bpf: Mixing bpf2bpf and tailcallsPu Lehui
In the current RV64 JIT, if we just don't initialize the TCC in subprog, the TCC can be propagated from the parent process to the subprocess, but the updated TCC of the parent process cannot be restored when the subprocess exits. Since the RV64 TCC is initialized before saving the callee saved registers into the stack, we cannot use the callee saved register to pass the TCC, otherwise the original value of the callee saved register will be destroyed. So we implemented mixing bpf2bpf and tailcalls similar to x86_64, i.e. using a non-callee saved register to transfer the TCC between functions, and saving that register to the stack to protect the TCC value. As for the tailcall hierarchy issue, inspired by the s390's low-overhead approach, we store TCC from RV_REG_TCC back to stack after calling bpf2bpf call or calling orig bpf func in bpf trampoline. Tests test_bpf.ko and test_verifier have passed, as well as the relative testcases of test_progs*. Signed-off-by: Pu Lehui <pulehui@huawei.com> Reviewed-by: Björn Töpel <bjorn@kernel.org> Acked-by: Björn Töpel <bjorn@kernel.org> Link: https://lore.kernel.org/bpf/20260708064436.2971933-7-pulehui@huaweicloud.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
12 daysriscv, bpf: Add RV_TAILCALL_OFFSET macro to format tailcall offsetPu Lehui
Add RV_TAILCALL_OFFSET macro to format tailcall offset, and correct the relevant comments. Signed-off-by: Pu Lehui <pulehui@huawei.com> Reviewed-by: Björn Töpel <bjorn@kernel.org> Acked-by: Björn Töpel <bjorn@kernel.org> Link: https://lore.kernel.org/bpf/20260708064436.2971933-6-pulehui@huaweicloud.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
12 daysriscv, bpf: Fix kernel stack corruption in tailcall with CFIPu Lehui
When CONFIG_CFI_CLANG is enabled, prog->bpf_func already skips the kcfi instruction during setup. Including it again in the tailcall jump offset causes it to jump over an extra 4 bytes, skipping the stack pointer adjustment, which will result in kernel stack corruption. Fixes: 30a59cc79754 ("riscv, bpf: Fix possible infinite tailcall when CONFIG_CFI_CLANG is enabled") Reported-by: Sashiko <sashiko-bot@kernel.org> Signed-off-by: Pu Lehui <pulehui@huawei.com> Reviewed-by: Björn Töpel <bjorn@kernel.org> Acked-by: Björn Töpel <bjorn@kernel.org> Link: https://lore.kernel.org/bpf/20260708064436.2971933-5-pulehui@huaweicloud.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
12 daysriscv, bpf: Using kvzalloc_objs to allocate cache bufferPu Lehui
It is unnecessary to allocate continuous physical memory for cache buffer, and when ebpf program is too large, it may cause memory allocation failure. Signed-off-by: Pu Lehui <pulehui@huawei.com> Reviewed-by: Björn Töpel <bjorn@kernel.org> Acked-by: Björn Töpel <bjorn@kernel.org> Link: https://lore.kernel.org/bpf/20260708064436.2971933-4-pulehui@huaweicloud.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
12 daysriscv, bpf: Fix memory leak in bpf_jit_freePu Lehui
When bpf_int_jit_compile() is called for subprograms, it returns early during the first pass (!prog->is_func || extra_pass is false), keeping ctx->offset alive for the subsequent extra pass. If JIT compilation fails for a later subprogram, the BPF core aborts and calls bpf_jit_free() to clean up the first subprogram. However, bpf_jit_free() fails to free jit_data->ctx.offset, which causes a memory leak of the JIT context offsets array. Fix this by adding the missing kfree(jit_data->ctx.offset) in bpf_jit_free(). Fixes: 48a8f78c50bd ("bpf, riscv: use prog pack allocator in the BPF JIT") Reported-by: Sashiko <sashiko-bot@kernel.org> Signed-off-by: Pu Lehui <pulehui@huawei.com> Reviewed-by: Björn Töpel <bjorn@kernel.org> Acked-by: Björn Töpel <bjorn@kernel.org> Link: https://lore.kernel.org/bpf/20260708064436.2971933-3-pulehui@huaweicloud.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
12 daysbpf: Extract the is_struct_ops_tramp helperPu Lehui
Extract the is_struct_ops_tramp helper, and use it in riscv as the current checks are somewhat hacky. Signed-off-by: Pu Lehui <pulehui@huawei.com> Reviewed-by: Björn Töpel <bjorn@kernel.org> Acked-by: Björn Töpel <bjorn@kernel.org> Link: https://lore.kernel.org/bpf/20260708064436.2971933-2-pulehui@huaweicloud.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
13 daysMerge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds
Pull kvm fixes from Paolo Bonzini: "RISC-V: - Avoid redundant allocations when allocating IMSIC page tables - Apply SBI FWFT LOCK flag only on successful set - Bound SBI PMU counter mask scan to BITS_PER_LONG, since on RV32 the PMU SBI start/stop helper can only access 32 PMU counters. - Skip TLB flush when G-stage PTE becomes valid if the Svvptc extension is available. - Always show Zicbo[m|z|p] block sizes in ONE_REG - Inject instruction access fault on unmapped guest fetch - Use raw spinlock for irqs_pending and irqs_pending_mask - Fix Spectre-v1 in vector register access via ONE_REG x86: - Fixes to SEV selftests - Once free_nested() did a VMCLEAR of shadow VMCS, there's no need to VMCLEAR it again if the kernel is preempted and thread migration happens - Preserve nested TDP shadow page tables if they are used as roots, instead of clearing them unnecessarily - Fix use of stale data if out-of-memory happens after vendor module reload - Check for invalid/obsolete root *after* making MMU pages available, because the latter can make a page invalid - Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN KVM: selftests: sev_init2_tests: Derive SEV availability from KVM KVM: selftests: sev_smoke_test: Only run VM types the host offers KVM: x86/mmu: Fix use-after-free on vendor module reload KVM: x86/mmu: Preserve nested TDP shadow page tables if they are used as roots KVM: x86: Check for invalid/obsolete root *after* making MMU pages available KVM: nVMX: Hide shadow VMCS right after VMCLEAR KVM: riscv: Fix Spectre-v1 in vector register access RISC-V: KVM: Serialize virtual interrupt pending state updates RISC-V: KVM: Inject instruction access fault on unmapped guest fetch RISC-V: KVM: Zicbo[m|z|p] block sizes should be always present in ONE_REG riscv: kvm: Skip TLB flush when G-stage PTE becomes valid with Svvptc KVM: riscv: PMU: Bound counter mask scan to BITS_PER_LONG KVM: riscv: SBI FWFT: Apply LOCK flag only on successful set RISC-V: KVM: Avoid redundant page-table allocations in ioremap topup
13 daysriscv: defconfig: thead: enable PCA953X GPIO driverMarek Szyprowski
Enable PCA953X GPIO driver to properly probe Wifi pwrseq driver on LicheePi4a board. Reviewed-by: Drew Fustini <fustini@kernel.org> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Drew Fustini <fustini@kernel.org>
13 daysentry, treewide: Make syscall_enter_from_user_mode[_work]() indicate syscall ↵Thomas Gleixner
execution The return values of syscall_enter_from_user_mode[_work]() are non-intuitive. Both functions return the syscall number which should be invoked by the architecture specific syscall entry code. The returned number can be: - the unmodified syscall number which was handed in by the caller - a modified syscall number (ptrace, seccomp, trace/probe/bpf) That has an additional twist. If the return value is -1L then the caller is not allowed to modify the return value as that indicates that the modifying entity requests to abort the syscall and set the return value already. That can obviously not be differentiated from a syscall which handed in -1 as syscall number. The most trivial way to deal with that is: set_return_value(regs, -ENOSYS); nr = syscall_enter_from_user_mode(regs, nr); if (valid(nr)) handle_syscall(regs, nr); That's what LOONGARCH, RISCV, and X86 do. But PowerPC and S390 do not preset the return value, so when user space hands in -1 and there is nothing setting the return value in the entry work code, then the syscall is skipped but the return value is whatever random data has been in the return value register. Change the return values of syscall_enter_from_user_mode[_work]() to boolean and return false, when either ptrace or seccomp request to skip the syscall. If they return true, update the syscall number as it might have been changed. That results in slightly different behaviour of the architectures versus tracing. If the syscall tracepoint has probe/BPF attached, those might set the syscall number to -1 and also set the return value. PowerPC and S390 will then overwrite that value with -ENOSYS. The other architectures will just ignore it like any other invalid syscall and use the modified one. Originally-by: Michal Suchánek <msuchanek@suse.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Michal Suchánek <msuchanek@suse.de> Link: https://patch.msgid.link/20260712141346.772209074@kernel.org
2026-07-15riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()Mark Harris
When cpusetsize < cpumask_size(), hwprobe_get_cpus() did not fully initialize its copy of the cpu mask, which could cause non-deterministic results from the riscv_hwprobe syscall on a system with more than 8 CPUs when the supplied cpu mask is empty. Address this by fully initializing the cpu mask. Fixes: e178bf146e4b ("RISC-V: hwprobe: Introduce which-cpus flag") Signed-off-by: Mark Harris <mark.hsj@gmail.com> Reviewed-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Michael Ellerman <mpe@kernel.org> Link: https://patch.msgid.link/20260714003056.73707-1-mark.hsj@gmail.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-15KVM: riscv: Fix Spectre-v1 in vector register accessZongmin Zhou
User-controlled register indices from the ONE_REG ioctl are used to index into the vector register buffer (v0..v31). Sanitize the calculated offset with array_index_nospec() to prevent speculative out-of-bounds access. Signed-off-by: Zongmin Zhou <zhouzongmin@kylinos.cn> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260715030818.75657-1-min_halo@163.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-07-15vdso: Rename HAVE_GENERIC_VDSO to VDSO_DATASTOREThomas Weißschuh
Over time the meaning of HAVE_GENERIC_VDSO has become off. Today it only controls the availability of the vDSO datastore. Rename the symbol to match its function. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Link: https://patch.msgid.link/20260709-vdso-have_generic_vdso-v1-6-d2e1061f268b@linutronix.de
2026-07-15vdso: Drop HAVE_GENERIC_VDSO from architecture kconfig filesThomas Weißschuh
Now that GENERIC_GETTIMEOFDAY and VDSO_GETRANDOM enable HAVE_GENERIC_VDSO automatically, the architecture specific kconfig files do not need to do so anymore. Remove the corresponding lines. Keep them for riscv, loongarch and powerpc as those have their own explicit usage of the vDSO datastore provided by HAVE_GENERIC_VDSO. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Link: https://patch.msgid.link/20260709-vdso-have_generic_vdso-v1-5-d2e1061f268b@linutronix.de
2026-07-15vdso: Remove the dependency on HAVE_GENERIC_VDSO from ARCH_HAS_VDSO_ARCH_DATAThomas Weißschuh
Align ARCH_HAS_VDSO_ARCH_DATA with ARCH_HAS_VDSO_TIME_DATA, making it selectable even without HAVE_GENERIC_VDSO. It will only have an effect when HAVE_GENERIC_VDSO is enabled anyways, but this makes the architecture Kconfig files a bit simpler. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Link: https://patch.msgid.link/20260709-vdso-have_generic_vdso-v1-2-d2e1061f268b@linutronix.de
2026-07-15RISC-V: KVM: Serialize virtual interrupt pending state updatesXie Bo
KVM RISC-V tracks guest local interrupt state with two bitmaps: - irqs_pending: interrupts that should be visible to the guest - irqs_pending_mask: interrupts whose pending state changed The current code updates those bitmaps with independent atomic bitops and assumes a multiple-producer, single-consumer protocol. That model does not actually hold. kvm_riscv_vcpu_sync_interrupts() is not a pure consumer. When the guest changes guest-visible HVIP state, sync_interrupts() writes both irqs_pending and irqs_pending_mask to reflect the new guest state back into KVM state. As a result, irqs_pending and irqs_pending_mask form a single logical state transition, but they are not updated atomically as a pair. This allows a race where a newly injected interrupt is lost. For example: CPU0 CPU1 ---- ---- kvm_riscv_vcpu_set_interrupt(VS_SOFT) set_bit(VS_SOFT, irqs_pending) kvm_riscv_vcpu_sync_interrupts() sees guest-cleared HVIP.VSSIP sets irqs_pending_mask clear_bit(IRQ_VS_SOFT, irqs_pending) set_bit(VS_SOFT, irqs_pending_mask) kvm_vcpu_kick() After that interleaving, a later flush can update HVIP without VSSIP even though a new virtual interrupt was injected. In practice, the guest can remain blocked in WFI with work pending. The same pending/mask protocol is shared by VS soft interrupts, PMU overflow delivery, and AIA high interrupt synchronization, so the race is not limited to one interrupt source. Fix this by serializing all updates to irqs_pending and irqs_pending_mask with a per-vCPU raw spinlock. This keeps the pending bit and the dirty mask as one state transition across: - set/unset interrupt - guest HVIP sync - interrupt flush to guest CSR state - vCPU reset - AIA CSR writes that clear dirty state Use non-atomic bitmap operations while holding the lock. Hold the lock across the AIA sync, flush, and pending checks as well, so both bitmap words share the same serialization domain. This intentionally replaces the existing lockless protocol instead of trying to repair it with additional barriers. The problem is not memory ordering on a single field; it is that two separate bitmaps encode one shared state machine while both producers and sync paths can modify them. A per-vCPU raw spinlock keeps the fix small, local, and suitable for backporting. Fixes: cce69aff689e ("RISC-V: KVM: Implement VCPU interrupts and requests handling") Cc: stable@vger.kernel.org Signed-off-by: Xie Bo <xb@ultrarisc.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260715020359.1521354-2-xb@ultrarisc.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-07-14arch/riscv: vdso: remove CFI landing pad from rt_sigreturnAurelien Jarno
When CONFIG_RISCV_USER_CFI is enabled, the CFI version of the vDSO, has a CFI landing pad instruction at the start of __vdso_rt_sigreturn. This breaks libgcc's unwinding code which matches on the first two instructions. Other unwinders that rely on similar instruction matching may also be affected. Since __vdso_rt_sigreturn is reached as part of signal-return handling rather than via an indirect call/jump from userspace, it does not need a CFI landing pad. Remove it and restore the instruction sequence expected by existing unwinding code. This matches what was done on arm64 in commit 9a964285572b ("arm64: vdso: Don't prefix sigreturn trampoline with a BTI C instruction") for a similar issue. Cc: stable@vger.kernel.org Fixes: 37f57bd3faea ("arch/riscv: compile vdso with landing pad and shadow stack note") Co-authored-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://patch.msgid.link/20260623204058.498120-1-aurelien@aurel32.net [pjw@kernel.org: fixed comment style] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-14syscall_user_dispatch: Introduce ARCH_SUPPORTS_SYSCALL_USER_DISPATCHJinjie Ruan
Currently, only x86 genuinely implements and supports Syscall User Dispatch (SUD). Multiple architectures provide a stub arch_syscall_is_vdso_sigreturn() returning 'false' simply to satisfy GENERIC_ENTRY compilation, which creates a false impression of feature support. Introduce ARCH_SUPPORTS_SYSCALL_USER_DISPATCH to decouple this mechanism from GENERIC_ENTRY. Select it exclusively on x86 and remove the redundant stub functions from other architectures. Suggested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20260713035422.582771-1-ruanjinjie@huawei.com
2026-07-14RISC-V: KVM: Inject instruction access fault on unmapped guest fetchQingwei Hu
When an instruction guest-page-fault targets a GPA that is not backed by any memslot, KVM has no MMIO emulation path for the fetch. Load and store guest-page faults can be routed through MMIO emulation, but an instruction fetch has no data payload or access size for userspace to complete in the same way. Treat this case as an architectural access fault in the guest. On bare metal, fetching from an inaccessible physical address raises an instruction access fault for the supervisor to handle through its trap vector. Reflect EXC_INST_ACCESS back to the guest so the guest observes the same class of exception rather than leaving the fetch as a host-handled condition. stval contains the virtual address of the portion of the instruction that caused the fault, while sepc points to the beginning of the instruction. Signed-off-by: Qingwei Hu <qingwei.hu@bytedance.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260707122548.281685-1-qingwei.hu@bytedance.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-07-13riscv: vdso: Do not use LTO for the vDSOThomas Weißschuh
With LTO enabled the compiler assumes that the vDSO functions are not used and optimizes them away completely. Currently this happens to __vdso_clock_getres(), __vdso_clock_gettime(), __vdso_getrandom(), __vdso_gettimeofday() and __vdso_riscv_hwprobe(). Disable LTO for the vDSO, as these functions are hand-optimized anyways. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202606301855.WvkSC4kD-lkp@intel.com/ Fixes: 021d23428bdb ("RISC-V: build: Allow LTO to be selected") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20260701-riscv-vdso-lto-v1-1-89db0cd82077@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-13riscv: io: avoid null-pointer arithmetic in PIO helpersYunhui Cui
When port I/O is not supported, exposing the port-string helpers is both unnecessary and can make clang diagnose null-pointer arithmetic from the PCI_IOBASE based address expression. Keep the MMIO string helpers available as before, but only provide the port I/O variants when CONFIG_HAS_IOPORT is enabled. Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260703122832.15984-2-cuiyunhui@bytedance.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-13riscv: Gate FUNCTION_ALIGNMENT_4B on DYNAMIC_FTRACERui Qi
The FUNCTION_ALIGNMENT_4B select forces the whole kernel to be built with -fmin-function-alignment=4. This alignment is only needed so the patchable-function-entry NOPs, which arch/riscv/Makefile emits under CONFIG_DYNAMIC_FTRACE, can be patched reliably on RISCV_ISA_C=y builds where compressed instructions otherwise allow 2-byte function alignment. The select is currently gated on HAVE_DYNAMIC_FTRACE, a capability bit that is selected whenever the toolchain supports dynamic ftrace, rather than on whether tracing is actually enabled. As a result every RISCV_ISA_C=y build gets 4-byte function alignment across the entire kernel even when function tracing is disabled, needlessly growing the kernel image and wasting instruction cache for a feature that is not in use. Gate the select on DYNAMIC_FTRACE instead, matching the condition under which arch/riscv/Makefile emits -fpatchable-function-entry, so the alignment is only applied when it is actually needed. Fixes: c41bf4326c7b ("riscv: ftrace: align patchable functions to 4 Byte boundary") Signed-off-by: Rui Qi <qirui.001@bytedance.com> Link: https://patch.msgid.link/20260706130415.463682-1-qirui.001@bytedance.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-13mm/sparse-vmemmap: flush_cache_vmap() after hotplugging vmemmapVivian Wang
section_activate() does not flush TLB after populating new vmemmap pages. On most architectures, this is okay. However it is a problem on RISC-V since there the TLB caching non-present entries is permitted, which causes spurious faults on some hardwares. This seems to be most easily reproduced with DEBUG_VM=y and PAGE_POISONING=y, which causes these newly mapped struct pages to be poisoned i.e. written to immediately after mapping. Extend the RISC-V flush_cache_vmap() to also handle the vmemmap range, and call it after hotplugging vmemmap, which gets the possible spurious fault handled in the exception handler. At least for now, the only other architecture with both SPARSEMEM_VMEMMAP and flush_cache_vmap() is PowerPC, which has a similar problem with newly valid PTEs. But there flush_cache_vmap() is just a ptesync. So it should be safe to do this for generic code while having minimal performance impact. Suggested-by: Muchun Song <muchun.song@linux.dev> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Reviewed-by: Muchun Song <muchun.song@linux.dev> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Link: https://patch.msgid.link/20260713-mark-after-vmemmap-populate-v6-2-b945ceba29d4@iscas.ac.cn Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-13riscv: mm: Make mark_new_valid_map() stuff depend on 64BIT && MMUVivian Wang
None of the code relating to mark_new_valid_map() does anything useful without CONFIG_64BIT=y && CONFIG_MMU=y, because the new_valid_map_cpus_check code is only used if CONFIG_64BIT, and the exception codes checked there can only happen with CONFIG_MMU=y. Therefore, make these conditional on CONFIG_64BIT=y && CONFIG_MMU=y to simplify programming, since we do not have to handle CONFIG_MMU=n when changing this code in the future. This also removes some unused code on the entry path for CONFIG_MMU=n. Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://patch.msgid.link/20260713-mark-after-vmemmap-populate-v6-1-b945ceba29d4@iscas.ac.cn Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-13RISC-V: KVM: Zicbo[m|z|p] block sizes should be always present in ONE_REGAnup Patel
All config and core registers of the KVM RISC-V ONE_REG interface are expected to be always available to the KVM user-space and the KVM get-reg-list selftest assumes these registers to be as base registers. Currently, the Zicbo[m|z|p] block size config registers are only available when corresponding ISA extension is present on the host which breaks the above expectation. In fact, KVM get-reg-list selftest fails when any of the Zicbo[m|z|p] ISA extension is not present on host. To address this issue, drop the ISA extension checks from kvm_riscv_vcpu_get/set_reg_config() and copy_config_reg_indices() functions. Fixes: 031f9efafc08 ("KVM: riscv: Add KVM_GET_REG_LIST API support") Fixes: a044ef71043e ("RISC-V: KVM: use ENOENT in *_one_reg() when extension is unavailable") Fixes: 48e2febcda74 ("RISC-V: KVM: Provide UAPI for Zicbop block size") Fixes: cf05b059d59f ("RISC-V: KVM: Introduce common kvm_riscv_isa_check_host()") Signed-off-by: Anup Patel <anup.patel@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260706181522.2003922-1-anup.patel@oss.qualcomm.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-07-13riscv: kvm: Skip TLB flush when G-stage PTE becomes valid with SvvptcDylan.Wu
The gstage_tlb_flush() in the kvm_riscv_gstage_set_pte() is not needed when an invalid G-stage PTE becomes valid and Svvptc extension is available because new valid PTEs become visible to the page-table walker within a bounded time. Assisted-by: YuanSheng: deepseek-v4-pro Co-developed-by: Quan Zhou <zhouquan@iscas.ac.cn> Signed-off-by: Quan Zhou <zhouquan@iscas.ac.cn> Signed-off-by: Dylan.Wu <fredwudi0305@gmail.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260701075239.95542-1-fredwudi0305@gmail.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-07-13KVM: riscv: PMU: Bound counter mask scan to BITS_PER_LONGShengwen Cheng
The PMU SBI handler passes the guest argument registers directly to the PMU start/stop helpers: kvm_riscv_vcpu_pmu_ctr_start(vcpu, cp->a0, cp->a1, cp->a2, ...) kvm_riscv_vcpu_pmu_ctr_stop(vcpu, cp->a0, cp->a1, cp->a2, ...) which map to: unsigned long ctr_base unsigned long ctr_mask unsigned long flags Thus cp->a1 is a single unsigned long ctr_mask, not a bitmap array sized for RISCV_MAX_COUNTERS. On RV32, RISCV_MAX_COUNTERS is 64 while BITS_PER_LONG is 32. Using for_each_set_bit() with RISCV_MAX_COUNTERS can therefore make find_next_bit() access bits beyond the storage of ctr_mask on RV32. Limit the scan to BITS_PER_LONG. The requested counter range is already validated by kvm_pmu_validate_counter_mask(), so this preserves RV64 behavior and avoids an out-of-bounds bitmap read on RV32. Fixes: 0cb74b65d2e5 ("RISC-V: KVM: Implement perf support without sampling") Signed-off-by: Shengwen Cheng <shengwen1997.tw@gmail.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260626054051.3360865-1-shengwen1997.tw@gmail.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-07-13KVM: riscv: SBI FWFT: Apply LOCK flag only on successful setSeungJu Cheon
kvm_sbi_fwft_set() applies the caller's flags to conf->flags before invoking the set() callback. If the callback returns an error, the LOCK bit persists and the feature becomes permanently locked without its value ever being changed. Move the flags assignment after the callback so LOCK takes effect only on success. Fixes: 6b72fd170592 ("RISC-V: KVM: add support for FWFT SBI extension") Signed-off-by: SeungJu Cheon <suunj1331@gmail.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260624130238.524706-1-suunj1331@gmail.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-07-13RISC-V: KVM: Avoid redundant page-table allocations in ioremap topupFangyu Yu
kvm_riscv_mmu_ioremap() currently tops up its on-stack page-table cache via kvm_mmu_topup_memory_cache(), which allocates up to KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE (32) objects per topup. ioremap only consumes non-leaf page-table pages, at most pgd_levels - 1 (1 to 4) per call, and for contiguous mappings within the same huge page the non-leaf pages are allocated once and reused by subsequent pages. Topping up to 32 objects therefore triggers many unnecessary GFP_KERNEL_ACCOUNT allocations on every call, all of which are freed when the function returns. In hot paths (such as vCPU migration), this creates avoidable allocator churn and wastes CPU cycles. Use __kvm_mmu_topup_memory_cache() with a capacity of pgd_levels so the on-stack cache is sized to the maximum demand of a single mapping. This removes the redundant allocations and reduces per-call overhead without changing behavior. Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Link: https://lore.kernel.org/r/20260610093922.51617-1-fangyu.yu@linux.alibaba.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-07-12riscv/syscall: Use syscall_enter_from_user_mode_randomize_stack()Thomas Gleixner
syscall_enter_from_user_mode_randomize_stack() replaces syscall_enter_from_user_mode() and the subsequent invocation of add_random_kstack_offset(). The advantage is that it applies the stack randomization right after enter_from_user_mode() and thereby avoids the overhead of get/put_cpu_var() as that code is invoked with interrupts disabled. No functional change. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Radu Rendec <radu@rendec.net> Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Reviewed-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com> Link: https://patch.msgid.link/20260707190253.974626922@kernel.org
2026-07-10riscv: dts: spacemit: k3: Enable SD card supportYixun Lan
Add the device tree node of SDHCI-0 controller which found on CoM260-IFX board, it's currenty used for Micro SD card slot, and one GPIO pin is configured as card insertion/removal detection pin, the slot use 4-bit data bus, and up support to SDR104 speed mode. Link: https://patch.msgid.link/20260610-07-k3-enable-sd-v1-1-196ae29bd091@kernel.org Signed-off-by: Yixun Lan <dlan@kernel.org>
2026-07-09ACPI: irq: Move RISC-V interrupt controllers autodep to ACPI IRQ codeLorenzo Pieralisi
RISC-V implements arch code to detect probe dependencies for devices and the interrupt controller the devices GSIs are routed to. The code itself is arch agnostic apart from an arch specific helper function required to retrieve the acpi_handle of the interrupt controller that manages the device GSI interrupt. In order to enable IRQ probe dependencies detection on other architectures, move RISC-V IRQ probe dependency detection code to generic ACPI IRQ code. Allow interrupt controller drivers to register an arch specific function to determine the acpi_handle for a specific GSI number to use the mechanism if needed by the respective interrupt controller drivers. Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com> Tested-by: Sunil V L <sunilvl@oss.qualcomm.com> Link: https://patch.msgid.link/20260709-gic-v5-acpi-iwb-probe-deferral-v4-5-48dae790f871@kernel.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-08riscv: defconfig: enable ARCH_ULTRARISCJia Wang
Enable `ARCH_ULTRARISC` in the default RISC-V defconfig. Signed-off-by: Jia Wang <wangjia@ultrarisc.com> Link: https://patch.msgid.link/20260515-ultrarisc-pinctrl-v1-9-bf559589ea8a@ultrarisc.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-08riscv: add UltraRISC SoC family Kconfig supportJia Wang
The first SoC in the UltraRISC series is UR-DP1000, containing octa UltraRISC CP100 cores. Signed-off-by: Jia Wang <wangjia@ultrarisc.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20260427-ultrarisc-pcie-v4-1-98935f6cdfb5@ultrarisc.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-07riscv: dts: spacemit: Use symbolic PDMA request numbers on K1Guodong Xu
The PDMA request numbers (DRQ) are fixed values specific to the SoC from a hardware perspective. The detailed definition can be found in K1 User Manual [1], Chapter 9.4.3 DMA Connectivity & Assignments. Add a DTS header file to define the symbolic names for the DRQs of non-secure DMA peripherals. Convert the K1 SPI3 node to these macros. Link: https://www.spacemit.com/community/document/info?lang=en&nodepath=hardware/key_stone/k1/k1_docs/k1_usermanual/9.Top_System.md [1] Signed-off-by: Guodong Xu <docular.xu@gmail.com> Reviewed-by: Yixun Lan <dlan@kernel.org> Link: https://patch.msgid.link/20260620-b4-k1-pdma-req-macros-v4-1-3cf77d0bd0d6@gmail.com Signed-off-by: Yixun Lan <dlan@kernel.org>
2026-07-06riscv: Prevent NULL pointer dereference in machine_kexec_prepare()Tao Liu
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 <bhe@redhat.com> Acked-by: Pratyush Yadav <pratyush@kernel.org> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com> Signed-off-by: Tao Liu <ltao@redhat.com> Link: https://patch.msgid.link/20260705232706.30265-2-ltao@redhat.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-07riscv: dts: allwinner: d1s-t113: Add uart4 pinctrl required by NetCube ↵Lukas Schmid
Systems OpenNMC Added the "uart4_pb_pins" pinctrl used by the OpenNMC Signed-off-by: Lukas Schmid <lukas.schmid@netcube.li> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Link: https://patch.msgid.link/20260606205452.2386930-3-lukas.schmid@netcube.li Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-07-03Merge tag 'riscv-for-linus-7.2-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux 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
2026-07-01bpf: Restrict JIT predictor flush to cBPFPawan Gupta
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 <pawan.kumar.gupta@linux.intel.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2026-07-01riscv: remove unreachable invalid range check in kasan_init()Sang-Heon Jeon
kasan_init() populates the linear mapping shadow with for_each_mem_range() and breaks the loop when start >= end. for_each_mem_range() never returns an invalid range, so start < end always. Therefore the start >= end check is unreachable, so remove it. No functional change. Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Reviewed-by: Andrey Ryabinin <ryabinin.a.a@gmail.com> Link: https://patch.msgid.link/20260630150413.1718632-5-ekffu200098@gmail.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-07-01riscv: remove unreachable invalid range check in ↵Sang-Heon Jeon
create_linear_mapping_page_table() create_linear_mapping_page_table() iterates memblock regions with for_each_mem_range() and breaks the loop when start >= end. for_each_mem_range() never returns an invalid range, so start < end always. Therefore the start >= end check is unreachable, so remove it. No functional change. Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Link: https://patch.msgid.link/20260630150413.1718632-4-ekffu200098@gmail.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-06-30riscv: probes: save original sp in rethook trampolineMartin Kaiser
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 ... [<ffffffff80016d16>] regs_get_kernel_stack_nth+0x26/0x38 [<ffffffff80177196>] process_fetch_insn+0x3ee/0x760 [<ffffffff80177836>] kretprobe_trace_func+0x116/0x1f0 [<ffffffff8017795a>] kretprobe_dispatcher+0x4a/0x58 [<ffffffff8013572e>] kretprobe_rethook_handler+0x5e/0x90 [<ffffffff80180838>] rethook_trampoline_handler+0x70/0x108 [<ffffffff8001ba32>] arch_rethook_trampoline_callback+0x12/0x1c [<ffffffff8001ba84>] arch_rethook_trampoline+0x48/0x94 [<ffffffff8067872a>] 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 <martin@kaiser.cx> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> 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 <pjw@kernel.org>
2026-06-30riscv: kexec_file: Add support for crashkernel CMA reservationJinjie Ruan
Commit 35c18f2933c5 ("Add a new optional ",cma" suffix to the crashkernel= command line option") and commit ab475510e042 ("kdump: implement reserve_crashkernel_cma") added CMA support for kdump crashkernel reservation. This allows the kernel to dynamically allocate contiguous memory for crash dumping when needed, rather than permanently reserving a fixed region at boot time. So extend crashkernel CMA reservation support to riscv. The following changes are made to enable CMA reservation: - Parse and obtain the CMA reservation size along with other crashkernel parameters. - Call reserve_crashkernel_cma() to allocate the CMA region for kdump. - Include the CMA-reserved ranges for kdump kernel to use, which was already done in of_kexec_alloc_and_setup_fdt(). - Exclude the CMA-reserved ranges from the crash kernel memory to prevent them from being exported through /proc/vmcore, which was already done in the crash core. Update kernel-parameters.txt to document CMA support for crashkernel on riscv architecture. Cc: Paul Walmsley <pjw@kernel.org> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Alexandre Ghiti <alex@ghiti.fr> Acked-by: Baoquan He <bhe@redhat.com> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Acked-by: Paul Walmsley <pjw@kernel.org> # arch/riscv Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://patch.msgid.link/20260629094746.191843-11-ruanjinjie@huawei.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-06-30riscv: kexec_file: Use crash_prepare_headers() helper to simplify codeJinjie Ruan
Use the newly introduced crash_prepare_headers() function to replace the existing prepare_elf_headers(), allocate cmem and exclude crash kernel memory in the crash core, which reduce code duplication. Only the following two architecture functions need to be implemented: - arch_get_system_nr_ranges(). Call get_nr_ram_ranges_callback() to pre-counts the max number of memory ranges. - arch_crash_populate_cmem(). Use prepare_elf64_ram_headers_callback() to collects the memory ranges and fills them into cmem. Cc: Paul Walmsley <pjw@kernel.org> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: Guo Ren <guoren@kernel.org> Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com> Acked-by: Baoquan He <bhe@redhat.com> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Guo Ren <guoren@kernel.org> Link: https://patch.msgid.link/20260629094746.191843-7-ruanjinjie@huawei.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-06-30riscv: kexec_file: Fix crashk_low_res not exclude bugJinjie Ruan
As done in commit 944a45abfabc ("arm64: kdump: Reimplement crashkernel=X") and commit 4831be702b95 ("arm64/kexec: Fix missing extra range for crashkres_low.") for arm64, while implementing crashkernel=X,[high,low], riscv should have excluded the "crashk_low_res" reserved ranges from the crash kernel memory to prevent them from being exported through /proc/vmcore, and the exclusion would need an extra crash_mem range. Just simply tested on qemu with crashkernel=4G with kexec in [1] mentioned in [2]. And the second kernel can be started normally. # dmesg | grep crash [ 0.000000] crashkernel low memory reserved: 0xf8000000 - 0x100000000 (128 MB) [ 0.000000] crashkernel reserved: 0x000000017fe00000 - 0x000000027fe00000 (4096 MB) [1]: https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2 [2]: https://lore.kernel.org/all/20230726175000.2536220-1-chenjiahao16@huawei.com/ Cc: Guo Ren <guoren@kernel.org> Cc: Baoquan He <bhe@redhat.com> Fixes: 5882e5acf18d ("riscv: kdump: Implement crashkernel=X,[high,low]") Reviewed-by: Guo Ren <guoren@kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2 Link: https://lore.kernel.org/all/20230726175000.2536220-1-chenjiahao16@huawei.com/ Link: https://patch.msgid.link/20260629094746.191843-2-ruanjinjie@huawei.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-06-25riscv: Fix 32-bit call_on_irq_stack() frame pointer ABISamuel Holland
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 <samuel.holland@sifive.com> Reviewed-by: Matthew Bystrin <dev.mbstr@gmail.com> Signed-off-by: Rui Qi <qirui.001@bytedance.com> Link: https://lore.kernel.org/all/20240530001733.1407654-2-samuel.holland@sifive.com/ Reviewed-by: Nam Cao <namcao@linutronix.de> 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 <pjw@kernel.org>
2026-06-25riscv: smp: use secs_to_jiffies in __cpu_upThorsten Blum
Use secs_to_jiffies() to simplify the code. Drop the redundant zero initialization while at it. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20260611232537.467398-3-thorsten.blum@linux.dev Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-06-25riscv: Add build salt to the vDSOBastian Blank
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 <waldi@debian.org> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/ajQY7n0an0YwQ--j@steamhammer.waldi.eu.org Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-06-25riscv: Raise default NR_CPUS for 64BIT to 256Vivian Wang
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 <lufei.zheng@spacemit.com> Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1140651 # [1] Suggested-by: Han Gao <gaohan@iscas.ac.cn> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://patch.msgid.link/20260625-riscv-more-nr-cpus-v1-1-5da8c72b9269@iscas.ac.cn Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-06-21Merge tag 'mm-nonmm-stable-2026-06-21-10-22' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull non-MM updates from Andrew Morton: - "taskstats: fix TGID dead-thread stat retention" (Yiyang Chen) Fix a taskstats TGID aggregation bug where fields added in the TGID query path were not preserved after thread exit, and adds a kselftest covering the regression. - "lib/tests: string_helpers: Slight improvements" (Andy Shevchenko) Improve lib/tests/string_helpers_kunit.c a little - "lib/base64: decode fixes" (Josh Law) Address minor issues in lib/base64.c - "selftests/filelock: Make output more kselftestish" (Mark Brown) Make the output from the ofdlocks test a bit easier for tooling to work with. Also ignore the generated file - "uaccess: unify inline vs outline copy_{from,to}_user() selection" (Yury Norov) Simplify the usercopy code by removing the selectability of inlining copy_{from,to}_user(). - "ocfs2: validate inline xattr header consumers" (ZhengYuan Huang) Fix a number of possible issues in the ocfs2 xattr code - "lib and lib/cmdline enhancements" (Dmitry Antipov) Provide additional robustness checking in the cmdline handling code and its in-kernel testing and selftests - "cleanup the RAID6 P/Q library" (Christoph Hellwig) Clean up the RAID6 P/Q library to match the recent updates to the RAID 5 XOR library and other CRC/crypto libraries - "ocfs2: harden inode validators against forged metadata" (Michael Bommarito) Add three structural checks to OCFS2 dinode validation so malformed on-disk fields are rejected before ocfs2_populate_inode() copies them into the in-core inode - "lib/raid: replace __get_free_pages() call with kmalloc()" (Mike Rapoport) Clean up the lib/raid code by using kmalloc() in more places * tag 'mm-nonmm-stable-2026-06-21-10-22' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (108 commits) ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits lib: interval_tree_test: validate benchmark parameters ocfs2: avoid moving extents to occupied clusters treewide: fix transposed "sign" typos and update spelling.txt ocfs2: fix UBSAN array-index-out-of-bounds in ocfs2_sum_rightmost_rec fat: reject BPB volumes whose data area starts beyond total sectors selftests/uevent: increase __UEVENT_BUFFER_SIZE to avoid ENOBUFS on busy systems lib/test_firmware: allocate the configured into_buf size fs: efs: remove unneeded debug prints checkpatch: cuppress warnings when Reported-by: is followed by Link: MAINTAINERS: add Alexander as a kcov reviewer mailmap: update Alexander Sverdlin's Email addresses fs: fat: inode: replace sprintf() with scnprintf() ocfs2: fix out-of-bounds write in ocfs2_remove_refcount_extent ocfs2: fix race between ocfs2_control_install_private() and ocfs2_control_release() ocfs2/dlm: require a ref for locking_state debugfs open ocfs2: reject FITRIM ranges shorter than a cluster ocfs2: validate fast symlink target during inode read ocfs2: add journal NULL check in ocfs2_checkpoint_inode() ...