linux.git/arch/riscv, branch v7.2 Linux kernel source tree riscv: lib: Fix ZBB strnlen reading past count boundary 2026-08-08T17:45:33+00:00 Michael Neuling mikey@neuling.org 2026-04-13T01:07:38+00:00 5d588c684833e678a0008eb69c33190f01a65f4b 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 <mikey@neuling.org> Assisted-by: Claude Opus4.6 High Thinking Link: https://patch.msgid.link/20260413010738.1622423-1-mikey@neuling.org Signed-off-by: Paul Walmsley <pjw@kernel.org> 
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 <mikey@neuling.org>
Assisted-by: Claude Opus4.6 High Thinking
Link: https://patch.msgid.link/20260413010738.1622423-1-mikey@neuling.org
Signed-off-by: Paul Walmsley <pjw@kernel.org>
 riscv: hwprobe: Register unaligned probes before usermode 2026-08-07T23:36:22+00:00 Rui Qi qirui.001@bytedance.com 2026-07-21T15:05:09+00:00 994dad686e755477e2b2700cca4e6e1a90a58bdc 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 <qirui.001@bytedance.com> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260721150511.1607105-1-qirui.001@bytedance.com Signed-off-by: Paul Walmsley <pjw@kernel.org> 
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 <qirui.001@bytedance.com>
Reviewed-by: Nam Cao <namcao@linutronix.de>
Link: https://patch.msgid.link/20260721150511.1607105-1-qirui.001@bytedance.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
 riscv: ftrace: Fix ftrace_modify_call failure on kprobed functions 2026-08-07T03:02:56+00:00 Pu Lehui pulehui@huawei.com 2026-08-02T09:49:29+00:00 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 [<ffffffff03c44c1c>] 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 ... [<ffffffff80008f4e>] ftrace_bug+0x46e/0x4b0 [<ffffffff803d3e86>] ftrace_replace_code+0x16e/0x170 [<ffffffff803d42b6>] ftrace_modify_all_code+0x12e/0x1b8 [<ffffffff800430f4>] arch_ftrace_update_code+0x14/0x28 [<ffffffff803e0324>] ftrace_startup+0x14c/0x2a0 [<ffffffff803e133c>] ftrace_startup_subops+0x584/0x1050 [<ffffffff804500e6>] register_ftrace_graph+0x4e6/0x1018 [<ffffffff804cf9f6>] register_fprobe_ips+0xc66/0x12f8 [<ffffffff8049abe8>] bpf_kprobe_multi_link_attach+0x5d8/0xe68 [<ffffffff8050fcaa>] __sys_bpf+0x3d5a/0x47f0 [<ffffffff805107ee>] __riscv_sys_bpf+0xae/0x168 [<ffffffff80034d78>] syscall_handler+0x60/0x100 [<ffffffff8228b4f4>] do_trap_ecall_u+0x174/0x208 [<ffffffff822b69c4>] 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 <pulehui@huawei.com> Link: https://patch.msgid.link/20260802094929.3978390-1-pulehui@huaweicloud.com [pjw@kernel.org: fixed reproducer in commit message] Signed-off-by: Paul Walmsley <pjw@kernel.org> 
We are frequently hitting the following splat during the riscv bpf
selftests:

00000000026dc75a: expected (7c3ff297) but got (00100073)
------------[ ftrace bug ]------------
ftrace failed to modify
[<ffffffff03c44c1c>] 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
...
[<ffffffff80008f4e>] ftrace_bug+0x46e/0x4b0
[<ffffffff803d3e86>] ftrace_replace_code+0x16e/0x170
[<ffffffff803d42b6>] ftrace_modify_all_code+0x12e/0x1b8
[<ffffffff800430f4>] arch_ftrace_update_code+0x14/0x28
[<ffffffff803e0324>] ftrace_startup+0x14c/0x2a0
[<ffffffff803e133c>] ftrace_startup_subops+0x584/0x1050
[<ffffffff804500e6>] register_ftrace_graph+0x4e6/0x1018
[<ffffffff804cf9f6>] register_fprobe_ips+0xc66/0x12f8
[<ffffffff8049abe8>] bpf_kprobe_multi_link_attach+0x5d8/0xe68
[<ffffffff8050fcaa>] __sys_bpf+0x3d5a/0x47f0
[<ffffffff805107ee>] __riscv_sys_bpf+0xae/0x168
[<ffffffff80034d78>] syscall_handler+0x60/0x100
[<ffffffff8228b4f4>] do_trap_ecall_u+0x174/0x208
[<ffffffff822b69c4>] 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 <pulehui@huawei.com>
Link: https://patch.msgid.link/20260802094929.3978390-1-pulehui@huaweicloud.com
[pjw@kernel.org: fixed reproducer in commit message]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
 Merge tag 'riscv-for-linus-7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux 2026-08-02T19:12:21+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-08-02T19:12:21+00:00 f5a7e2ae5f0a9a5caf59501457938eeb249a7dc8 Pull RISC-V fixes from Paul Walmsley: - Fix swiotlb initialization on systems where DRAM is located above 4GiB (such as the Tenstorrent Blackhole cards) - Fix an out-of-bounds access in the memory hot-remove code that can occur on Sv39 and Sv48 systems - Avoid oopsing during boot if the SBI component of the unaligned access performance checking code loses a race against __init function freeing - Avoid attempting to install the debug-enabled vDSO when it shouldn't be built due to !CONFIG_MMU - Avoid some sparse warnings by adding missing __iomem notations in get_cycles{,_hi}() - Drop an unnecessary runtime warning in the SiFive errata handler * tag 'riscv-for-linus-7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: vdso: Only try to install vDSO when present riscv: mm: Fix out-of-bounds page-table walk during memory hot-remove riscv: drop __init from vec_check_unaligned_access_speed_all_cpus riscv: mm: fix SWIOTLB initialization for systems with DRAM above 4GB riscv/sifive: remove warning in errata riscv: time: Add missing __iomem in get_cycles() and get_cycles_hi() 
Pull RISC-V fixes from Paul Walmsley:

 - Fix swiotlb initialization on systems where DRAM is located above
   4GiB (such as the Tenstorrent Blackhole cards)

 - Fix an out-of-bounds access in the memory hot-remove code that can
   occur on Sv39 and Sv48 systems

 - Avoid oopsing during boot if the SBI component of the unaligned
   access performance checking code loses a race against __init function
   freeing

 - Avoid attempting to install the debug-enabled vDSO when it shouldn't
   be built due to !CONFIG_MMU

 - Avoid some sparse warnings by adding missing __iomem notations in
   get_cycles{,_hi}()

 - Drop an unnecessary runtime warning in the SiFive errata handler

* tag 'riscv-for-linus-7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  riscv: vdso: Only try to install vDSO when present
  riscv: mm: Fix out-of-bounds page-table walk during memory hot-remove
  riscv: drop __init from vec_check_unaligned_access_speed_all_cpus
  riscv: mm: fix SWIOTLB initialization for systems with DRAM above 4GB
  riscv/sifive: remove warning in errata
  riscv: time: Add missing __iomem in get_cycles() and get_cycles_hi()
riscv: vdso: Only try to install vDSO when present 2026-07-29T23:55:17+00:00 Thomas Weißschuh thomas.weissschuh@linutronix.de 2026-07-09T06:49:00+00:00 c052927905710de1ab7364bf1925efbd12517ea3 vdso.so.dbg is only built with CONFIG_MMU. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202607090258.iSAUYlO1-lkp@intel.com/ Fixes: f157d411a9eb ("riscv: add missing vdso_install target") Fixes: 3edf39916977 ("vDSO, kbuild: Provide vDSO debug variants at runtime") Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20260709-riscv-install-vdso-v1-1-0ba4345419ca@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org> 
vdso.so.dbg is only built with CONFIG_MMU.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202607090258.iSAUYlO1-lkp@intel.com/
Fixes: f157d411a9eb ("riscv: add missing vdso_install target")
Fixes: 3edf39916977 ("vDSO, kbuild: Provide vDSO debug variants at runtime")
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Link: https://patch.msgid.link/20260709-riscv-install-vdso-v1-1-0ba4345419ca@linutronix.de
Signed-off-by: Paul Walmsley <pjw@kernel.org>
 riscv: mm: Fix out-of-bounds page-table walk during memory hot-remove 2026-07-29T23:35:05+00:00 Karl Mehltretter kmehltretter@gmail.com 2026-07-29T01:21:32+00:00 a0188cc133696627857d16054e43f9ebc7efc821 remove_pud_mapping() and remove_p4d_mapping() obtain a child table base with pud_offset(p4dp, 0) and p4d_offset(pgd, 0), then add the index for addr. RISC-V folds page-table levels at runtime. When a level is folded, its offset helper returns the parent entry itself, but the index can still be nonzero. Adding it walks past the parent table. Sv48 folds P4D, while Sv39 folds both P4D and PUD, so memory hot-remove can descend into unrelated memory and pass an invalid page to __free_pages(). This can trigger: kernel BUG at include/linux/mm.h:1810! VM_BUG_ON_PAGE(page_ref_count(page) == 0) arch_remove_memory+0x1e/0x5c try_remove_memory+0x15e/0x200 remove_memory+0x24/0x3c Only add the index when the corresponding page-table level is enabled, matching p4d_offset() and pud_offset(). Fixes: c75a74f4ba19 ("riscv: mm: Add memory hotplugging support") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Link: https://patch.msgid.link/20260729012132.24882-1-kmehltretter@gmail.com Signed-off-by: Paul Walmsley <pjw@kernel.org> 
remove_pud_mapping() and remove_p4d_mapping() obtain a child table base
with pud_offset(p4dp, 0) and p4d_offset(pgd, 0), then add the index for
addr.

RISC-V folds page-table levels at runtime. When a level is folded, its
offset helper returns the parent entry itself, but the index can still be
nonzero. Adding it walks past the parent table. Sv48 folds P4D, while Sv39
folds both P4D and PUD, so memory hot-remove can descend into unrelated
memory and pass an invalid page to __free_pages(). This can trigger:

  kernel BUG at include/linux/mm.h:1810!
  VM_BUG_ON_PAGE(page_ref_count(page) == 0)
  arch_remove_memory+0x1e/0x5c
  try_remove_memory+0x15e/0x200
  remove_memory+0x24/0x3c

Only add the index when the corresponding page-table level is enabled,
matching p4d_offset() and pud_offset().

Fixes: c75a74f4ba19 ("riscv: mm: Add memory hotplugging support")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Link: https://patch.msgid.link/20260729012132.24882-1-kmehltretter@gmail.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
 riscv: drop __init from vec_check_unaligned_access_speed_all_cpus 2026-07-29T19:24:24+00:00 Anirudh Srinivasan asrinivasan@oss.tenstorrent.com 2026-06-12T16:24:43+00:00 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] [<ffffffff80a04ef8>] vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.760964] [<ffffffff80047a10>] kthread+0xd8/0xfc [ 25.764660] [<ffffffff80010c48>] ret_from_fork_kernel+0x18/0x1c4 [ 25.769220] [<ffffffff80895fe6>] 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 <asrinivasan@oss.tenstorrent.com> 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 <pjw@kernel.org> 
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] [<ffffffff80a04ef8>] vec_check_unaligned_access_speed_all_cpus+0x18/0x2c
[   25.760964] [<ffffffff80047a10>] kthread+0xd8/0xfc
[   25.764660] [<ffffffff80010c48>] ret_from_fork_kernel+0x18/0x1c4
[   25.769220] [<ffffffff80895fe6>] 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 <asrinivasan@oss.tenstorrent.com>
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 <pjw@kernel.org>
 riscv: mm: fix SWIOTLB initialization for systems with DRAM above 4GB 2026-07-29T17:43:50+00:00 Troy Mitchell troy.mitchell@linux.dev 2026-07-27T08:08:44+00:00 cfca5a48b03fbd33c8cb84cb73ee2e34467f3a33 On RISC-V platforms where the entire physical memory (DRAM) resides above the 32-bit address space (i.e., above dma32_phys_limit), the current SWIOTLB initialization logic fails. This patch addresses two interconnected issues on such platforms: 1. Incorrect 32-bit DMA bounce assumption: The existing condition `max_pfn > PFN_DOWN(dma32_phys_limit)` assumes that a 32-bit DMA bounce buffer is required simply because the maximum PFN exceeds the 32-bit limit. However, if all DRAM starts above 4GB, no memory exists below the limit to satisfy this allocation. Fix this by adding a check to ensure `memblock_start_of_DRAM()` is actually below the 32-bit limit before enforcing 32-bit SWIOTLB. 2. kmalloc() bounce buffer allocation failure on non-coherent systems: For non-coherent DMA, kmalloc() buffers whose sizes are not cache-line-aligned still require bouncing, even if 32-bit DMA bouncing is skipped. Without the `SWIOTLB_ANY` flag, swiotlb_init() defaults to allocating from low memory, which fails completely when DRAM only exists in high memory. By appending `SWIOTLB_ANY` to swiotlb_flags, the allocator is permitted to allocate this bounce buffer from high memory. With this patch, systems with non-coherent DMA and DRAM entirely above 4GB can successfully map the software IO TLB in high memory and boot normally. Tested-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com> Signed-off-by: Troy Mitchell <troy.mitchell@linux.dev> Link: https://patch.msgid.link/20260727-fix-riscv-swiotlb-v3-1-59479b23736c@linux.dev Reviewed-by: Drew Fustini <fustini@kernel.org> Signed-off-by: Paul Walmsley <pjw@kernel.org> 
On RISC-V platforms where the entire physical memory (DRAM) resides
above the 32-bit address space (i.e., above dma32_phys_limit), the
current SWIOTLB initialization logic fails.

This patch addresses two interconnected issues on such platforms:

1. Incorrect 32-bit DMA bounce assumption:
The existing condition `max_pfn > PFN_DOWN(dma32_phys_limit)` assumes
that a 32-bit DMA bounce buffer is required simply because the maximum
PFN exceeds the 32-bit limit. However, if all DRAM starts above 4GB,
no memory exists below the limit to satisfy this allocation. Fix
this by adding a check to ensure `memblock_start_of_DRAM()` is actually
below the 32-bit limit before enforcing 32-bit SWIOTLB.

2. kmalloc() bounce buffer allocation failure on non-coherent systems:
For non-coherent DMA, kmalloc() buffers whose sizes are not
cache-line-aligned still require bouncing, even if 32-bit DMA bouncing
is skipped. Without the `SWIOTLB_ANY` flag, swiotlb_init() defaults to
allocating from low memory, which fails completely when DRAM only exists
in high memory. By appending `SWIOTLB_ANY` to swiotlb_flags, the allocator
is permitted to allocate this bounce buffer from high memory.

With this patch, systems with non-coherent DMA and DRAM entirely above
4GB can successfully map the software IO TLB in high memory and boot
normally.

Tested-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
Signed-off-by: Troy Mitchell <troy.mitchell@linux.dev>
Link: https://patch.msgid.link/20260727-fix-riscv-swiotlb-v3-1-59479b23736c@linux.dev
Reviewed-by: Drew Fustini <fustini@kernel.org>
Signed-off-by: Paul Walmsley <pjw@kernel.org>
 riscv/sifive: remove warning in errata 2026-07-29T17:43:28+00:00 Yong-Xuan Wang yongxuan.wang@sifive.com 2026-07-29T17:43:28+00:00 9a22a1542ca03381dcbf000d7a264cbee61e7203 The alternative patching of sifive vendor extensions also calls the sifive_errata_patch_func(), but the patch_id of the vendor extension (ext + RISCV_VENDOR_EXT_ALTERNATIVES_BASE) is always larger than ERRATA_SIFIVE_NUMBER. Remove this unnecessary warning. Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Link: https://patch.msgid.link/20260503-sifive_errata-v1-1-6f12a81bc267@sifive.com [pjw@kernel.org: drop unnecessary braces] Signed-off-by: Paul Walmsley <pjw@kernel.org> 
The alternative patching of sifive vendor extensions also calls the
sifive_errata_patch_func(), but the patch_id of the vendor extension
(ext + RISCV_VENDOR_EXT_ALTERNATIVES_BASE) is always larger than
ERRATA_SIFIVE_NUMBER. Remove this unnecessary warning.

Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com>
Link: https://patch.msgid.link/20260503-sifive_errata-v1-1-6f12a81bc267@sifive.com
[pjw@kernel.org: drop unnecessary braces]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
riscv: time: Add missing __iomem in get_cycles() and get_cycles_hi() 2026-07-29T17:43:28+00:00 Nam Cao namcao@linutronix.de 2026-07-29T17:43:28+00:00 779e0eb18c774b81a462a6ee89cfbc9eb2d3cee5 __iomem is missing while calling readl_relaxed() in get_cycles() and get_cycles_hi() and sparse complains. Add __iomem to silence the sparse warnings. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202607160619.14G8GHp5-lkp@intel.com/ Signed-off-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260716053319.2178937-1-namcao@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org> 
__iomem is missing while calling readl_relaxed() in get_cycles() and
get_cycles_hi() and sparse complains.

Add __iomem to silence the sparse warnings.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202607160619.14G8GHp5-lkp@intel.com/
Signed-off-by: Nam Cao <namcao@linutronix.de>
Link: https://patch.msgid.link/20260716053319.2178937-1-namcao@linutronix.de
Signed-off-by: Paul Walmsley <pjw@kernel.org>