linux-kernel - Re: [PATCH v3] riscv: fix using wrong load type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250819-cf406b3d02087824245b5576@orel>
Date: Tue, 19 Aug 2025 13:23:32 -0500
From: Andrew Jones <ajones@...tanamicro.com>
To: Jimmy Ho <jimmy.ho@...ive.com>
Cc: linux-riscv@...ts.infradead.org, troy.mitchell@...ux.spacemit.com, 
	ziyao@...root.org, paul.walmsley@...ive.com, palmer@...belt.com, 
	aou@...s.berkeley.edu, alex@...ti.fr, cyrilbur@...storrent.com, cleger@...osinc.com, 
	charlie@...osinc.com, kees@...nel.org, ben.dooks@...ethink.co.uk, jszhang@...nel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] riscv: fix using wrong load type

On Tue, Aug 19, 2025 at 03:13:18PM +0800, Jimmy Ho wrote:
> thread_info.cpu field is 32 bits wide,
> but is accessed using an XLEN-bit load, which might be 64bit load, fix it
> 
> Changes in v3:
> - replace space with tab to keep it aligned with code block
> - Add "Fixes" tag
> 
> Changes in v2:
> - add a comment to explain why use lw instead of REG_L.
> - correct commit message

The changelog belongs below the --- in the patch.

> 
> Fixes: 503638e0babf3 ("riscv: Stop emitting preventive sfence.vma for new vmalloc mappings")
> Signed-off-by: Jimmy Ho <jimmy.ho@...ive.com>
> ---
>  arch/riscv/kernel/entry.S | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
> index 3a0ec6fd5956..492ae936dccd 100644
> --- a/arch/riscv/kernel/entry.S
> +++ b/arch/riscv/kernel/entry.S
> @@ -45,8 +45,10 @@
>  	 * Computes:
>  	 * a0 = &new_vmalloc[BIT_WORD(cpu)]
>  	 * a1 = BIT_MASK(cpu)
> +	 * 
> +	 * using lw instead of REG_L is because the thread_info.cpu field is 32 bits wide
>  	 */
> -	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
> -- 
> 2.39.3

Otherwise,

Reviewed-by: Andrew Jones <ajones@...tanamicro.com>