Re: [PATCH v3 6/8] sparc64: add SPARC64 VII CPU, MMU and SMP support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] sparc64: missing membar #Sync in VII __flush_tlb_mm and xcall_flush_tlb_mm
- [High] sparc64: off-by-one error in VII TLB slot verification loop causes false panic
--

commit 83e75cdd0104cea9f29069ae3640894a08ee2f5f
Author: Magnus Lindholm <linmag7@gmail.com>
Subject: sparc64: add SPARC64 VII CPU, MMU and SMP support

This commit adds support for SPARC64 VII CPU, MMU, and SMP hardware paths.
It handles topology, interrupt dispatch, restrained ECC handling, and
synchronizes context writes and instruction demaps for supported firmware
modes.

Link: https://lore.kernel.org/oe-kbuild-all/202610121549.5ejZQ08o-lkp@intel.com/

> diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
> --- a/arch/sparc/mm/init_64.c
> +++ b/arch/sparc/mm/init_64.c
[ ... ]
> @@ -675,6 +675,50 @@ static unsigned long kern_large_tte(unsigned long paddr);
>  
> +/*
> + * Reserve two 4MB kernel mappings and an adjacent slot in the lower half
> + * of the fully associative bank. Check existing reservations, firmware
> + * status and physical slot readback before using the mappings.
> + */
> +static void __init vii_check_slots(void)
> +{
> +	int i;
> +
> +	if (num_kernel_image_mappings > 2) {
> +		prom_printf("VII-BOOT: kernel exceeds initial 8MB mapping budget\n");
> +		prom_halt();
> +	}
> +	for (i = 15 - num_kernel_image_mappings; i <= 15; i++) {
> +		unsigned long d = cheetah_get_ldtlb_data(i);

[Severity: High]
Does this loop bounds check evaluate an extra unallocated slot?

Since remap_kernel() exclusively populates slots tlb_ent - i, the kernel
only uses slots 14 and 15 when num_kernel_image_mappings is 2. However,
evaluating 15 - num_kernel_image_mappings results in iterating through
slots 13, 14, and 15.

If the firmware legitimately uses slot 13 for its own translations, will
this false conflict cause the kernel to incorrectly panic and halt on boot?

> diff --git a/arch/sparc/mm/ultra.S b/arch/sparc/mm/ultra.S
> --- a/arch/sparc/mm/ultra.S
> +++ b/arch/sparc/mm/ultra.S
[ ... ]
> +	.globl		sparc64_vii_patch_cachetlbops
> +sparc64_vii_patch_cachetlbops:
> +	save		%sp, -128, %sp
> +
> +	sethi		%hi(__flush_tlb_mm), %o0
> +	or		%o0, %lo(__flush_tlb_mm), %o0
> +	sethi		%hi(__cheetah_flush_tlb_mm), %o1
> +	or		%o1, %lo(__cheetah_flush_tlb_mm), %o1
> +	call		tlb_patch_one

[Severity: Critical]
Does patching __flush_tlb_mm with __cheetah_flush_tlb_mm violate the VII
hardware synchronization requirements?

The commit message notes that VII requires a membar #Sync to safely
synchronize context writes and instruction demaps, but __cheetah_flush_tlb_mm
lacks this barrier after restoring ASI_DMMU.

Could this omission cause the hardware to execute the demap against the
wrong MMU context, leading to silent TLB corruption during process address
space teardowns like exit() or large munmap() operations?

[ ... ]
> +	sethi		%hi(__flush_tlb_kernel_range), %o0
> +	or		%o0, %lo(__flush_tlb_kernel_range), %o0
> +	sethi		%hi(__vii_flush_tlb_kernel_range_patch), %o1
> +	or		%o1, %lo(__vii_flush_tlb_kernel_range_patch), %o1
> +	call		tlb_patch_one
> +	 mov		3, %o2
> +
> +#ifdef CONFIG_SMP
> +	sethi		%hi(xcall_flush_tlb_page), %o0
> +	or		%o0, %lo(xcall_flush_tlb_page), %o0
> +	sethi		%hi(__vii_xcall_flush_tlb_page_patch), %o1
> +	or		%o1, %lo(__vii_xcall_flush_tlb_page_patch), %o1
> +	call		tlb_patch_one
> +	 mov		3, %o2
> +
> +	/* VII uses 32-entry fTLBs: do not use the Spitfire 64-slot sweep. */
> +	sethi		%hi(xcall_flush_tlb_kernel_range), %o0

[Severity: Critical]
Is xcall_flush_tlb_mm unintentionally omitted from being patched here?

Failing to patch xcall_flush_tlb_mm causes SMP cross-CPU MM flushes on VII
to fall back to the generic Spitfire default.

Since the Spitfire default also lacks the necessary membar #Sync
synchronization before its DEMAP instructions, this appears to leave a path
for TLB corruption on SMP.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261012184826.986050-1-linmag7@gmail.com?part=6