From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>,
linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
Gregory CLEMENT <gregory.clement@bootlin.com>
Subject: Re: [PATCH v2] MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow
Date: Wed, 26 Nov 2025 20:18:30 +0100 [thread overview]
Message-ID: <aSdShmTVEmmGQ5v1@alpha.franken.de> (raw)
In-Reply-To: <alpine.DEB.2.21.2511261847410.36486@angie.orcam.me.uk>
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 ]
next prev parent reply other threads:[~2025-11-26 19:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-25 21:39 [PATCH v2] MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow Thomas Bogendoerfer
2025-11-26 18:52 ` Maciej W. Rozycki
2025-11-26 19:18 ` Thomas Bogendoerfer [this message]
2025-11-26 20:45 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aSdShmTVEmmGQ5v1@alpha.franken.de \
--to=tsbogend@alpha.franken.de \
--cc=gregory.clement@bootlin.com \
--cc=jiaxun.yang@flygoat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=macro@orcam.me.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox