[PATCH 2/3] riscv: use lw instead of REG_L when reading int cpu

Alexandre Ghiti alex at ghiti.fr
Fri Jul 25 07:21:30 PDT 2025


On 7/22/25 18:05, Radim Krčmář wrote:
> REG_L is wrong, because thread_info.cpu is 32-bit, not xlen-bit wide.
> The struct currently has a hole after cpu, so little endian accesses
> seemed fine.
>
> Fixes: be97d0db5f44 ("riscv: VMAP_STACK overflow detection thread-safe")
> Fixes: 503638e0babf ("riscv: Stop emitting preventive sfence.vma for new vmalloc mappings")
> Signed-off-by: Radim Krčmář <rkrcmar at ventanamicro.com>
> ---
>   arch/riscv/include/asm/asm.h | 2 +-
>   arch/riscv/kernel/entry.S    | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/riscv/include/asm/asm.h b/arch/riscv/include/asm/asm.h
> index b3022bc224ec..93b1e4ce34d1 100644
> --- a/arch/riscv/include/asm/asm.h
> +++ b/arch/riscv/include/asm/asm.h
> @@ -91,7 +91,7 @@
>   #endif
>   
>   .macro asm_per_cpu dst sym tmp
> -	REG_L \tmp, TASK_TI_CPU(tp)
> +	lw    \tmp, TASK_TI_CPU(tp)
>   	slli  \tmp, \tmp, PER_CPU_OFFSET_SHIFT
>   	la    \dst, __per_cpu_offset
>   	add   \dst, \dst, \tmp
> diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
> index 75656afa2d6b..4fdf187a62bf 100644
> --- a/arch/riscv/kernel/entry.S
> +++ b/arch/riscv/kernel/entry.S
> @@ -46,7 +46,7 @@
>   	 * a0 = &new_vmalloc[BIT_WORD(cpu)]
>   	 * a1 = BIT_MASK(cpu)
>   	 */
> -	REG_L 	a2, TASK_TI_CPU(tp)
> +	lw	a2, TASK_TI_CPU(tp)
>   	/*
>   	 * Compute the new_vmalloc element position:
>   	 * (cpu / 64) * 8 = (cpu >> 6) << 3


I went across the same kind of bug a week ago, thanks for catching this one.

You can add:

Reviewed-by: Alexandre Ghiti <alexghiti at rivosinc.com>

Though, to get backported to stable kernels, it will be easier if you 
split this patch into 2 independent patches as it will fail to apply on 
older releases. And it should not be dependent on the renaming of 
TASK_TI_CPU_NUM.

Please also add:

Cc: <stable at vger.kernel.org>

So that they will get backported automatically.

Thanks again for the catch,

Alex





More information about the linux-riscv mailing list