linux-kernel - Re: [PATCH v2] MIPS: mm: kmalloc tlb

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: <aSdShmTVEmmGQ5v1@alpha.franken.de>
Date: Wed, 26 Nov 2025 20:18:30 +0100
From: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
To: "Maciej W. Rozycki" <macro@...am.me.uk>
Cc: Jiaxun Yang <jiaxun.yang@...goat.com>, linux-mips@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Gregory CLEMENT <gregory.clement@...tlin.com>
Subject: Re: [PATCH v2] MIPS: mm: kmalloc tlb_vpn array to avoid stack
 overflow

On Wed, Nov 26, 2025 at 06:52:07PM +0000, Maciej W. Rozycki wrote:
> On Tue, 25 Nov 2025, Thomas Bogendoerfer wrote:
> 
> > 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.
> 
>  Hmm, I get:
> 
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 0 at arch/mips/mm/tlb-r4k.c:540 tlb_init+0x2a0/0x4bc
> Modules linked in:
> CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.18.0-rc1-dirty #60 NONE
> Hardware name: mti,malta
> Stack : 00000000 00000004 00000000 0000001d 809d1d2c 00000000 00000100 80944048
>         809d91bc 80944048 80a16a73 00000000 80b634a4 00000001 809d1ce0 809f7bc8
>         00000000 00000000 80944048 0000001f 00000001 809d1c14 00000000 653a206d
>         00000000 80b656d4 80b6570b 00000000 00000000 00000000 80944048 00000000
>         00000000 0000021c 80a40000 00000000 00000000 00000020 00000000 800472a4
>         ...
> Call Trace:
> [<80112bd8>] show_stack+0x28/0xf0
> [<8010a69c>] dump_stack_lvl+0x48/0x7c
> [<8012fedc>] __warn+0x9c/0x118
> [<801015e8>] warn_slowpath_fmt+0x58/0xa4
> [<8012ba84>] tlb_init+0x2a0/0x4bc
> [<80114738>] per_cpu_trap_init+0x17c/0x27c
> [<80a1d0f8>] trap_init+0xf0/0x794
> [<80a19ae4>] start_kernel+0x3c4/0x598
> 
> ---[ end trace 0000000000000000 ]---
> 
> exactly here:
> 
> > +	tlb_vpns = kmalloc_array(tlbsize, sizeof(unsigned long), GFP_KERNEL);
> > +	if (WARN_ON(!tlb_vpns))
> > +		return; /* Pray local_flush_tlb_all() is good enough. */
> 
> I'll try to find out more, but right now this doesn't appear to work.

kmalloc() doesn't work at that point :-( It only fixed the problem, because
we skip unification... d'oh

Thomas.

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