linux-kernel - Re: [GIT PULL] MIPS fixes for v6.18

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: <aSWMWVCXTV5Kl9eq@alpha.franken.de>
Date: Tue, 25 Nov 2025 12:00:41 +0100
From: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
To: "Maciej W. Rozycki" <macro@...am.me.uk>
Cc: Gregory CLEMENT <gregory.clement@...tlin.com>,
	torvalds@...ux-foundation.org, linux-mips@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] MIPS fixes for v6.18

On Tue, Nov 25, 2025 at 07:32:16AM +0000, Maciej W. Rozycki wrote:
> On Mon, 24 Nov 2025, Thomas Bogendoerfer wrote:
> 
> > > > Maciej W. Rozycki (2):
> > > >       MIPS: Malta: Fix !EVA SOC-it PCI MMIO
> > > >       MIPS: mm: Prevent a TLB shutdown on initial uniquification
> > > 
> > > Today, the kernel v6.18-rc7 no longer boots on EyeQ5 and EyeQ6H (MIPS
> > > I6500)-based boards. After a git bisect between v6.18-rc6 and v6.18-rc7,
> > > we found that the culprit is the commit "MIPS: mm: Prevent a TLB
> > > shutdown on initial uniquification".
> > > 
> > > Here is the log from a vanilla v6.18-rc7:
> > 
> > [..]
> > 
> > I guess your cores have more than 64 TLB entries. The Octeon CPU has
> > 256 entries... Patch below fixes the issue there.
> > 
> > Thomas.
> > 
> > >From b74abcb21103519ae48726c715d39a6aa3f57462 Mon Sep 17 00:00:00 2001
> > From: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
> > Date: Mon, 24 Nov 2025 22:46:43 +0100
> > Subject: [PATCH] MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow
> > 
> > Latest MIPS cores could have much more than 64 TLB entries, therefore
> > allocate array for unification instead of placing a too small array
> > on stack.
> 
>  Thank you for chasing this up.
> 
>  Indeed, in the absence of a cross-reference from Config1.MMUSize in the 
> ISA manual I missed the somewhat recent addition of Config4.MMUSizeExt and 
> VTLB/FTLB MMU features I haven't dealt with before.  I've looked through 
> the relevant documents and ISTM there's nothing else needed here so let's 
> hope your fix covers it all.
> 
>  For the record, the I6500 has a documented TLB size of 16 VTLB + 512 FTLB 
> entries and the array needs to hold them all.  Though for VTLB/FTLB we 
> necessarily rely on the EntryHi.EHINV feature, which means we could skip 
> the call to `r4k_tlb_uniquify' altogether.  Something for a possible later 
> improvement, I suppose.
> 
> > diff --git a/arch/mips/mm/tlb-r4k.c b/arch/mips/mm/tlb-r4k.c
> > index 3facf7cc6c7d..577055b50c41 100644
> > --- a/arch/mips/mm/tlb-r4k.c
> > +++ b/arch/mips/mm/tlb-r4k.c
> > @@ -524,15 +524,19 @@ static int r4k_vpn_cmp(const void *a, const void *b)
> >   */
> >  static void r4k_tlb_uniquify(void)
> >  {
> > -	unsigned long tlb_vpns[1 << MIPS_CONF1_TLBS_SIZE];
> >  	int tlbsize = current_cpu_data.tlbsize;
> >  	int start = num_wired_entries();
> > +	unsigned long *tlb_vpns;
> >  	unsigned long vpn_mask;
> >  	int cnt, ent, idx, i;
> >  
> >  	vpn_mask = GENMASK(cpu_vmbits - 1, 13);
> >  	vpn_mask |= IS_ENABLED(CONFIG_64BIT) ? 3ULL << 62 : 1 << 31;
> >  
> > +	tlb_vpns = kmalloc_array(tlbsize, sizeof(unsigned long), GFP_KERNEL);
> > +	if (!tlb_vpns)
> > +		return; /* pray local_flush_tlb_all() is good enough */
> 
>  I can't say I'm particularly happy with this bail-out hack, but then I 
> have nothing better in my mind right now, so OK, but can you please make 
> the comment a proper sentence (starting with a capital letter and ending 
> with a full stop)?

I'll add a WARN_ON() to inform users about the issue, but as this is
pretty early during boot, I don't think anybody will see it.

Thomas.

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