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

riscv: unaligned: stop using kthread for check_vector_unaligned_access()

2026-09-07T15:22:43+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: Fix register corruption from uninitialized cregs on error

2026-09-02T12:31:46+00:00

[ Upstream commit 6ebcbb53fc9bc30843054ed99fd60b8e542628f4 ]

compat_riscv_gpr_set() calls cregs_to_regs() unconditionally, even when
user_regset_copyin() fails. Since cregs is an uninitialized stack
variable, a copyin failure causes uninitialized stack data to be written
into the target task's pt_regs, corrupting its register state and
potentially leaking kernel stack contents.

compat_restore_sigcontext() has the same issue: it calls cregs_to_regs()
even when __copy_from_user() fails, leading to the same corruption of
the signal-returning task's register state on error.

Only call cregs_to_regs() when the user copy succeeds.

Fixes: 4608c159594f ("riscv: compat: ptrace: Add compat_arch_ptrace implement")
Fixes: 7383ee05314b ("riscv: compat: signal: Add rt_frame implementation")
Signed-off-by: Michael Neuling 
Assisted-by: Cursor:claude-4.6-opus-high-thinking
Link: https://patch.msgid.link/20260501062320.2339562-1-mikey@neuling.org
Signed-off-by: Paul Walmsley 
Signed-off-by: Sasha Levin

riscv: ftrace: Fix ftrace_modify_call failure on kprobed functions

2026-08-23T12:27:07+00:00

[ Upstream commit 2820d227ad4ee70805d693d698437cc3e88d6c3d ]

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 
Signed-off-by: Sasha Levin

riscv: drop __init from vec_check_unaligned_access_speed_all_cpus

2026-08-09T18:25:08+00:00

[ Upstream commit f51fed61eea0daba2f95f1a6074085e4cd513c7b ]

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 
Signed-off-by: Sasha Levin

riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()

2026-08-03T09:21:34+00:00

[ Upstream commit 5caae1deee89a6582c761d5dcd4b924b744426cc ]

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 
Signed-off-by: Sasha Levin

riscv: vdso: Do not use LTO for the vDSO

2026-07-24T14:17:17+00:00

commit ad6dcfa023762e37962f77ee48e752b7570e9440 upstream.

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 
Signed-off-by: Greg Kroah-Hartman

riscv: Prevent NULL pointer dereference in machine_kexec_prepare()

2026-07-24T14:17:16+00:00

commit 81bbcff0c053c4f5c711c31a9b72fc492bd96c3f upstream.

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 
Signed-off-by: Greg Kroah-Hartman

riscv: probes: save original sp in rethook trampoline

2026-07-24T14:17:15+00:00

commit bc7b086a45521a986a49045907f017e3e46c763e upstream.

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 
Signed-off-by: Greg Kroah-Hartman

riscv: cacheinfo: Fix node reference leak in populate_cache_leaves

2026-07-24T14:17:01+00:00

commit bf4a195f063b0a0805c1417f6aad1dd32ea48f0f upstream.

Currently, the while loop drops the reference to prev in each iteration.
If the loop terminates early due to a break, the final of_node_put(np)
correctly drops the reference to the current node.

However, if the loop terminates naturally because np == NULL, calling
of_node_put(np) is a no-op. This leaves the last valid node stored in
prev without its reference dropped, resulting in a node reference leak.

Fix this by changing the final `of_node_put(np)` to `of_node_put(prev)`.

Fixes: 94f9bf118f1e ("RISC-V: Fix of_node_* refcount")
Cc: stable@vger.kernel.org
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Zishun Yi 
Link: https://patch.msgid.link/20260509074040.1747800-1-vulab@iscas.ac.cn
Signed-off-by: Paul Walmsley 
Signed-off-by: Greg Kroah-Hartman

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

2026-07-24T14:16:40+00:00

[ Upstream commit c4c7756a81b5baef286bf9be1ea404f3e4dd7a3c ]

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 
Signed-off-by: Sasha Levin