Re: [PATCH 2/2] MIPS: mm: do not write a huge TLB entry when the probe misses

[Thomas Bogendoerfer <tsbogend@alpha.franken.de>]

On Tue, Sep 15, 2026 at 07:13:25AM +0000, Orgad Shaneh wrote:
> __update_tlb() probes for the 8K pair at the address it is given and,
> for a huge pmd, writes the huge entry with tlbwi at the probed index or
> with tlbwr when the probe misses. That works only if the caller passes
> the faulting address, so that the probe finds the 4K entry the refill
> handler loaded for the faulting page and the huge entry replaces it.
> 
> update_mmu_cache_pmd() is not called that way. do_set_pmd() has always
> passed the huge-aligned address, and since commit ebcfc63d6bca ("mm:
> abstract THP allocation") the anonymous THP fault path does too
> (map_anon_folio_pmd()). The probe then misses the stale 4K entry, which
> sits at the faulting page somewhere else in the 2 MB range, tlbwr adds
> a huge entry next to it, and the TLB holds two entries matching the
> faulting address. Octeon raises "Machine Check exception - caused by
> multiple matching entries in the TLB" on the next refill of that page;
> a process on a CN63XX board died this way within a second of start, on
> the first anonymous THP of its bss.
> 
> Skip the write when the probe misses. The refill and TLBL/TLBS handlers
> probe the faulting address themselves and rewrite the stale entry with
> the huge one (they also set the software young bit), so the entry is
> installed on the next access at the cost of one exception.
> 
> Fixes: fd062c847a8c ("MIPS: TLB support for hugetlbfs.")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Orgad Shaneh <orgads@gmail.com>
> ---
> diff --git a/arch/mips/mm/tlb-r4k.c b/arch/mips/mm/tlb-r4k.c
> --- a/arch/mips/mm/tlb-r4k.c
> +++ b/arch/mips/mm/tlb-r4k.c
> @@ -332,6 +332,19 @@ void __update_tlb(struct vm_area_struct * vma, unsigned long address, pte_t pte)
>  	/* this could be a huge page  */
>  	if (pmd_leaf(*pmdp)) {
>  		unsigned long lo;
> +
> +		/*
> +		 * The probe above only covers the 8K pair at @address, and
> +		 * a huge mapping is installed with the huge-aligned address
> +		 * while the refill that started the fault left a 4K entry
> +		 * for the faulting page elsewhere in the range. Writing the
> +		 * huge entry to a random index would leave two entries
> +		 * matching the faulting address; leave it to the refill and
> +		 * TLBL/TLBS handlers, which probe the faulting address.
> +		 */
> +		if (idx < 0)
> +			goto out;
> +
>  		write_c0_pagemask(PM_HUGE_MASK);
>  		ptep = (pte_t *)pmdp;
>  		lo = pte_to_entrylo(pte_val(*ptep));
> @@ -339,10 +352,7 @@ void __update_tlb(struct vm_area_struct * vma, unsigned long address, pte_t pte)
>  		write_c0_entrylo1(lo + (HPAGE_SIZE >> 7));
>  
>  		mtc0_tlbw_hazard();
> -		if (idx < 0)
> -			tlb_write_random();
> -		else
> -			tlb_write_indexed();
> +		tlb_write_indexed();
>  		tlbw_use_hazard();
>  		write_c0_pagemask(PM_DEFAULT_MASK);
>  	} else
> @@ -380,6 +390,7 @@ void __update_tlb(struct vm_area_struct * vma, unsigned long address, pte_t pte)
>  			tlb_write_indexed();
>  	}
>  	tlbw_use_hazard();
> +out:

If CONFIG_MIPS_HUGE_TLB_SUPPORT is unset, the not needed out: gives
a warning. I've fixed that while applying.

>  	htw_start();
>  	flush_micro_tlb_vm(vma);
>  
> -- 
> 2.47.0

applied to mips-next

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]