linux.git/arch/riscv/kernel, branch v7.2

riscv: hwprobe: Register unaligned probes before usermode

2026-08-07T23:36:22+00:00

The hwprobe vDSO data is populated by the first riscv_hwprobe syscall.
Some values, such as MISALIGNED_VECTOR_PERF, may depend on the async
vector unaligned access speed probe registered by
check_unaligned_access_all_cpus().

That initcall currently runs at late_initcall level. However,
rootfs_initcall enables usermode helpers before late initcalls run, so an
early helper can execute userspace and call riscv_hwprobe first.

In that case complete_hwprobe_vdso_data() consumes the initial
pending_boot_probes reference, populates the vDSO cache, and marks it
ready before the later async probe is registered. The eventual probe
result then cannot update the already-ready cache.

Move check_unaligned_access_all_cpus() to fs_initcall_sync. This still
runs after clocksource_done_booting(), so the ktime_get_mono_fast_ns()
benchmark uses a stable clocksource, but it runs before rootfs_initcall
enables usermode helpers.

Any async hwprobe probe is therefore registered before userspace can
trigger the one-time vDSO cache population.

Cc: stable@vger.kernel.org
Fixes: 6455c6c11827 ("riscv: Clean up & optimize unaligned scalar access probe")
Signed-off-by: Rui Qi 
Reviewed-by: Nam Cao 
Link: https://patch.msgid.link/20260721150511.1607105-1-qirui.001@bytedance.com
Signed-off-by: Paul Walmsley

riscv: ftrace: Fix ftrace_modify_call failure on kprobed functions

2026-08-07T03:02:56+00:00

We are frequently hitting the following splat during the riscv bpf
selftests:

00000000026dc75a: expected (7c3ff297) but got (00100073)
------------[ ftrace bug ]------------
ftrace failed to modify
[] bpf_kfunc_common_test+0x4/0x20 [bpf_testmod]
 actual:   e7:82:c2:ce
Updating ftrace call site to call a different ftrace function
ftrace record flags: 80100002
 (2)
 expected tramp: ffffffff80043904
------------[ cut here ]------------
WARNING: kernel/trace/ftrace.c:2278 at ftrace_bug+0x46e/0x4b0, CPU#1: test_progs/98
...
[] ftrace_bug+0x46e/0x4b0
[] ftrace_replace_code+0x16e/0x170
[] ftrace_modify_all_code+0x12e/0x1b8
[] arch_ftrace_update_code+0x14/0x28
[] ftrace_startup+0x14c/0x2a0
[] ftrace_startup_subops+0x584/0x1050
[] register_ftrace_graph+0x4e6/0x1018
[] register_fprobe_ips+0xc66/0x12f8
[] bpf_kprobe_multi_link_attach+0x5d8/0xe68
[] __sys_bpf+0x3d5a/0x47f0
[] __riscv_sys_bpf+0xae/0x168
[] syscall_handler+0x60/0x100
[] do_trap_ecall_u+0x174/0x208
[] handle_exception+0x16c/0x178

After debugging, it can be triggered by similar commands below:
```
echo do_nanosleep > set_ftrace_filter
echo function > current_tracer
echo 'p do_nanosleep' > kprobe_events
echo 1 > events/kprobes/enable
echo 'f do_nanosleep' > dynamic_events
echo 1 > events/fprobes/enable
```

The reason is that attaching a kprobe to an ftrace-traced function entry
replaces its initial auipc insn with ebreak. When ftrace_modify_call
later runs, it expects auipc insn, so verification fails and triggers
ftrace_bug.

The expected auipc logic remains conceptually unchanged, and kprobe
single-stepping ensures normal execution. Therefore, if the first insn
is ebreak, bypassing the check to continue patching the jalr insn is
safe and avoids ftrace failures.

Fixes: b2137c3b6d7a ("riscv: ftrace: prepare ftrace for atomic code patching")
Signed-off-by: Pu Lehui 
Link: https://patch.msgid.link/20260802094929.3978390-1-pulehui@huaweicloud.com
[pjw@kernel.org: fixed reproducer in commit message]
Signed-off-by: Paul Walmsley

riscv: drop __init from vec_check_unaligned_access_speed_all_cpus

2026-07-29T19:24:24+00:00

This function runs within a kthread and need not necessarily finish
before system finishes boot and free_initmem() unmaps the .init.text
section. This function makes calls to SBI for probing unaligned access
speed, and if this is slow for some reason (say some debug prints were
added to SBI), the kthread can still be running at this point and result
in an instruction page fault when trying to fetch from the freed region.

[   25.642087] Unable to handle kernel paging request at virtual address ffffffff80a04ef8
[   25.646694] Current vec_check_unali pgtable: 4K pagesize, 48-bit VAs, pgdp=0x00004000316e9000
[   25.653170] [ffffffff80a04ef8] pgd=000010004be7e401, p4d=000010004be7e401, pud=000010004be7e001, pmd=000010000c3000e3
[   25.661244] Oops [#1]
[   25.662997] Modules linked in:
[   25.665357] CPU: 3 UID: 0 PID: 42 Comm: vec_check_unali Not tainted 7.0.0-tt-blackhole-asrinivasan-00007-g30ff73f18211 #570 PREEMPTLAZY
[   25.674669] Hardware name: Tenstorrent Blackhole (DT)
[   25.678545] epc : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c
[   25.683458]  ra : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c
[   25.688372] epc : ffffffff80a04ef8 ra : ffffffff80a04ef8 sp : ffff8f8000203e20
[   25.693874]  gp : ffffffff814dc168 tp : ffffaf8001ad9900 t0 : 0000000000000000
[   25.699401]  t1 : fffffffffffffff0 t2 : ffffaf8001ad9a10 s0 : ffff8f8000203e30
[   25.704912]  s1 : ffffaf80018dc780 a0 : 0000000000000000 a1 : 0000000000000002
[   25.710407]  a2 : 00000000000001f0 a3 : 0000000000000018 a4 : 0000000000000000
[   25.715917]  a5 : 0000000000000000 a6 : ffffaf8001c03d98 a7 : ffffaf8001c03e30
[   25.721419]  s2 : ffff8f8000023c98 s3 : ffffaf8001aa1240 s4 : ffffffff80a04ee0
[   25.726937]  s5 : 0000000000000000 s6 : 0000000000000000 s7 : 0000000000000000
[   25.732450]  s8 : 0000000000000000 s9 : 0000000000000000 s10: 0000000000000000
[   25.737944]  s11: 0000000000000000 t3 : 0000000000000002 t4 : 0000000000000402
[   25.743481]  t5 : 0000000000000040 t6 : 0000000000000004 ssp : 0000000000000000
[   25.749024] status: 0000000200000120 badaddr: ffffffff80a04ef8 cause: 000000000000000c
[   25.755060] [] vec_check_unaligned_access_speed_all_cpus+0x18/0x2c
[   25.760964] [] kthread+0xd8/0xfc
[   25.764660] [] ret_from_fork_kernel+0x18/0x1c4
[   25.769220] [] ret_from_fork_kernel_asm+0x16/0x18
[   25.774018] Code: cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc (cccc) cccc

Drop __init from its signature so that this doesn't happen.

Fixes: a00e022be531 ("riscv: Annotate unaligned access init functions")
Signed-off-by: Anirudh Srinivasan 
Assisted-by: Claude:claude-opus-4-6
Link: https://patch.msgid.link/20260612-vec_unaligned_drop_init-v1-1-df969210ae34@oss.tenstorrent.com
Signed-off-by: Paul Walmsley

riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()

2026-07-15T17:12:40+00:00

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 
Reviewed-by: Nam Cao 
Reviewed-by: Michael Ellerman 
Link: https://patch.msgid.link/20260714003056.73707-1-mark.hsj@gmail.com
Signed-off-by: Paul Walmsley

arch/riscv: vdso: remove CFI landing pad from rt_sigreturn

2026-07-15T01:34:38+00:00

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 
Signed-off-by: Aurelien Jarno 
Signed-off-by: Joel Stanley 
Link: https://patch.msgid.link/20260623204058.498120-1-aurelien@aurel32.net
[pjw@kernel.org: fixed comment style]
Signed-off-by: Paul Walmsley

riscv: vdso: Do not use LTO for the vDSO

2026-07-13T18:08:27+00:00

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 
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 
Link: https://patch.msgid.link/20260701-riscv-vdso-lto-v1-1-89db0cd82077@linutronix.de
Signed-off-by: Paul Walmsley

riscv: mm: Make mark_new_valid_map() stuff depend on 64BIT && MMU

2026-07-13T17:29:52+00:00

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 
Link: https://patch.msgid.link/20260713-mark-after-vmemmap-populate-v6-1-b945ceba29d4@iscas.ac.cn
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

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