Re: [PATCH v3 6/9] riscv: kexec: Switch to trampoline page table before norelocate

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Missing `sfence.vma` after clearing `CSR_SATP` causes a fatal Instruction Page Fault on kexec.
--

commit 4cdd8f4ea42becec74890b3443cd153befa568f3
Author: Fangyu Yu <fangyu.yu@linux.alibaba.com>

riscv: kexec: Switch to trampoline page table before norelocate

This commit updates riscv_kexec_norelocate to act as a two-pass trampoline,
allowing it to drop kernel page tables while still executing from a mapped
address. It also replaces the previous stvec-based exception handoff with a
direct jump to the target entry.

> diff --git a/arch/riscv/kernel/kexec_relocate.S b/arch/riscv/kernel/kexec_relocate.S
> index af6b99f5b0fd9..8cfdf6f4032a8 100644
> --- a/arch/riscv/kernel/kexec_relocate.S
> +++ b/arch/riscv/kernel/kexec_relocate.S
[ ... ]
> @@ -198,14 +220,8 @@ SYM_CODE_START(riscv_kexec_norelocate)
>  	csrw	CSR_SCAUSE, zero
>  	csrw	CSR_SSCRATCH, zero
>  
> -	/*
> -	 * Switch to physical addressing
> -	 * This will also trigger a jump to CSR_STVEC
> -	 * which in this case is the address of the new
> -	 * kernel.
> -	 */
> -	csrw	CSR_STVEC, a2
>  	csrw	CSR_SATP, zero
> +	jr	a2
>  
>  SYM_CODE_END(riscv_kexec_norelocate)

[Severity: Critical]
Does this sequence require an sfence.vma instruction after clearing
CSR_SATP?

According to the RISC-V Privileged Architecture specification, writes to the
satp register do not imply any synchronization. A subsequent instruction fetch
may still use the old satp value unless explicitly synchronized with an
sfence.vma instruction.

Without sfence.vma, the CPU pipeline is allowed to fetch the instruction at
a2 (the start of the new kernel) using the old satp value. Because a2 is a
physical address and is not identity-mapped in the trampoline page table,
this fetch could trigger an instruction page fault.

Since the stvec override was removed by this patch, the trap would attempt
to vector to the old kernel's default trap handler. As that handler is also
unmapped in the trampoline, this sequence appears to result in a double fault
and a system hang during kexec.

If a similar pattern is introduced for riscv_kexec_relocate_entry later in
this series, it might also need an sfence.vma to avoid a page fault when
fetching the relocation code.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260604132418.15725-1-fangyu.yu@linux.alibaba.com?part=6