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

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: Fix 32-bit call_on_irq_stack() frame pointer ABI

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

call_on_irq_stack() uses struct member offsets to set up its link in the
frame record list. On riscv32, struct stackframe is the wrong size to
maintain stack pointer alignment, so STACKFRAME_SIZE_ON_STACK includes
padding. However, the ABI requires the frame record to be placed
immediately below the address stored in s0, so the padding must come
before the struct members.

Fix the layout by making STACKFRAME_FP and STACKFRAME_RA the negative
offsets from s0, instead of the positive offsets from sp.

Fixes: 82982fdd5133 ("riscv: Deduplicate IRQ stack switching")
Signed-off-by: Samuel Holland 
Reviewed-by: Matthew Bystrin 
Signed-off-by: Rui Qi 
Link: https://lore.kernel.org/all/20240530001733.1407654-2-samuel.holland@sifive.com/
Reviewed-by: Nam Cao 
Link: https://patch.msgid.link/20260624113148.3723541-1-qirui.001@bytedance.com
[pjw@kernel.org: cleaned up the patch tags and added Matthew's Reviewed-by]
Signed-off-by: Paul Walmsley

riscv: mm: Unconditionally sfence.vma for spurious fault

2026-06-07T05:48:15+00:00

Svvptc does not guarantee that it's safe to just return here. Since we
have already cleared our bit, if, theoretically, the bounded timeframe
for the accessed page to become valid still hasn't happened after sret,
we could fault again and actually crash.

Hopefully, these spurious faults should be rare enough that this is an
acceptable slowdown.

Cc: stable@vger.kernel.org
Fixes: 503638e0babf ("riscv: Stop emitting preventive sfence.vma for new vmalloc mappings")
Signed-off-by: Vivian Wang 
Link: https://patch.msgid.link/20260303-handle-kfence-protect-spurious-fault-v2-5-f80d8354d79d@iscas.ac.cn
Signed-off-by: Paul Walmsley

riscv: mm: Rename new_vmalloc into new_valid_map_cpus

2026-06-07T05:48:15+00:00

Since this mechanism is now used for the kfence pool, which comes from
the linear mapping and not vmalloc, rename new_vmalloc into
new_valid_map_cpus to avoid misleading readers.

No functional change intended.

Signed-off-by: Vivian Wang 
Link: https://patch.msgid.link/20260303-handle-kfence-protect-spurious-fault-v2-3-f80d8354d79d@iscas.ac.cn
Signed-off-by: Paul Walmsley

riscv: kfence: Call mark_new_valid_map() for kfence_unprotect()

2026-06-07T05:48:15+00:00

In kfence_protect_page(), which kfence_unprotect() calls, we cannot send
IPIs to other CPUs to ask them to flush TLB. This may lead to those CPUs
spuriously faulting on a recently allocated kfence object despite it
being valid, leading to false positive use-after-free reports.

Fix this by calling mark_new_valid_map() so that the page fault handling
code path notices the spurious fault and flushes TLB then retries the
access.

Update the comment in handle_exception to indicate that
new_valid_map_cpus_check also handles kfence_unprotect() spurious
faults.

Note that kfence_protect() has the same stale TLB entries problem, but
that leads to false negatives, which is fine with kfence.

Cc: stable@vger.kernel.org
Reported-by: Yanko Kaneti 
Fixes: b3431a8bb336 ("riscv: Fix IPIs usage in kfence_protect_page()")
Signed-off-by: Vivian Wang 
Link: https://patch.msgid.link/20260303-handle-kfence-protect-spurious-fault-v2-2-f80d8354d79d@iscas.ac.cn
Signed-off-by: Paul Walmsley

riscv: add hardware error trap handler support

2026-04-05T00:42:44+00:00

Add support for handling hardware error traps (exception code 19)
in the RISC-V architecture. The changes include:

- Add do_trap_hardware_error function declaration in asm-prototypes.h
- Add hardware error trap vector entry in entry.S exception vector table
- Implement do_trap_hardware_error handler in traps.c that generates
  SIGBUS with BUS_MCEERR_AR for hardware errors

This enables proper handling of hardware error exceptions that may occur
in RISC-V systems, providing appropriate error reporting and signal
generation for user space processes.

Signed-off-by: Rui Qi 
Link: https://patch.msgid.link/20260202094200.53735-1-qirui.001@bytedance.com
[pjw@kernel.org: clean up commit message slightly]
Signed-off-by: Paul Walmsley

riscv/traps: Introduce software check exception and uprobe handling

2026-01-29T09:38:40+00:00

The Zicfiss and Zicfilp extensions introduce a new exception, the
'software check exception', in the privileged ISA, with cause code =
18. This patch implements support for software check exceptions.

Additionally, the patch implements a CFI violation handler which
checks the code in the xtval register. If xtval=2, the software check
exception happened because of an indirect branch that didn't land on a
4 byte aligned PC or on a 'lpad' instruction, or the label value
embedded in 'lpad' didn't match the label value set in the x7
register. If xtval=3, the software check exception happened due to a
mismatch between the link register (x1 or x5) and the top of shadow
stack (on execution of `sspopchk`).

In case of a CFI violation, SIGSEGV is raised with code=SEGV_CPERR.
SEGV_CPERR was introduced by the x86 shadow stack patches.

To keep uprobes working, handle the uprobe event first before
reporting the CFI violation in the software check exception
handler. This is because, when the landing pad is activated, if the
uprobe point is set at the lpad instruction at the beginning of a
function, the system triggers a software check exception instead of an
ebreak exception due to the exception priority. This would prevent
uprobe from working.

Reviewed-by: Zong Li
Co-developed-by: Zong Li
Signed-off-by: Zong Li
Signed-off-by: Deepak Gupta
Tested-by: Andreas Korb # QEMU, custom CVA6
Tested-by: Valentin Haudiquet
Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-15-b55691eacf4f@rivosinc.com
[pjw@kernel.org: cleaned up the patch description]
Signed-off-by: Paul Walmsley

riscv: Implement indirect branch tracking prctls

2026-01-29T09:38:40+00:00

This patch adds a RISC-V implementation of the following prctls:
PR_SET_INDIR_BR_LP_STATUS, PR_GET_INDIR_BR_LP_STATUS and
PR_LOCK_INDIR_BR_LP_STATUS.

Reviewed-by: Zong Li 
Signed-off-by: Deepak Gupta 
Tested-by: Andreas Korb 
Tested-by: Valentin Haudiquet 
Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-14-b55691eacf4f@rivosinc.com
[pjw@kernel.org: clean up patch description]
Signed-off-by: Paul Walmsley

riscv: Add usercfi state for task and save/restore of CSR_SSP on trap entry/exit

2026-01-26T04:09:53+00:00

Carve out space in the RISC-V architecture-specific thread struct for
cfi status and shadow stack in usermode.

This patch:
- defines a new structure cfi_status with status bit for cfi feature
- defines shadow stack pointer, base and size in cfi_status structure
- defines offsets to new member fields in thread in asm-offsets.c
- saves and restores shadow stack pointer on trap entry (U --> S) and exit
  (S --> U)

Shadow stack save/restore is gated on feature availability and is
implemented using alternatives. CSR_SSP can be context-switched in
'switch_to' as well, but as soon as kernel shadow stack support gets
rolled in, the shadow stack pointer will need to be switched at trap
entry/exit point (much like 'sp'). It can be argued that a kernel
using a shadow stack deployment scenario may not be as prevalent as
user mode using this feature. But even if there is some minimal
deployment of kernel shadow stack, that means that it needs to be
supported.  Thus save/restore of shadow stack pointer is implemented
in entry.S instead of in 'switch_to.h'.

Reviewed-by: Charlie Jenkins 
Reviewed-by: Zong Li 
Reviewed-by: Alexandre Ghiti 
Signed-off-by: Deepak Gupta 
Tested-by: Andreas Korb  # QEMU, custom CVA6
Tested-by: Valentin Haudiquet 
Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-5-b55691eacf4f@rivosinc.com
[pjw@kernel.org: cleaned up patch description]
Signed-off-by: Paul Walmsley

riscv: entry: fix typo in comment 'instruciton' -> 'instruction'

2025-10-10T01:36:45+00:00

Fix a typo in a comment in the RISC-V entry.S.

Signed-off-by: Florian Schmaus 
Link: https://lore.kernel.org/r/20251006093742.53925-1-flo@geekplace.eu
[pjw@kernel.org: wrote a basic patch description]
Signed-off-by: Paul Walmsley