linux-kernel - Re: maple_tree.c:3738:1: error: the frame size of 1040 bytes is larger than 1024 bytes

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] [day] [month] [year] [list]

Message-ID: <20251205090546.69158d85@pumpkin>
Date: Fri, 5 Dec 2025 09:05:46 +0000
From: David Laight <david.laight.linux@...il.com>
To: Christian Kujau <lists@...dbynature.de>
Cc: Tiffany Yang <ynaffit@...gle.com>, linux-kernel@...r.kernel.org, "Liam
 R. Howlett" <Liam.Howlett@...cle.com>, Arnd Bergmann <arnd@...db.de>
Subject: Re: maple_tree.c:3738:1: error: the frame size of 1040 bytes is
 larger than 1024 bytes

On Fri, 5 Dec 2025 01:49:00 +0100 (CET)
Christian Kujau <lists@...dbynature.de> wrote:

> Hi Tiffany,
> 
> On Tue, 25 Nov 2025, Tiffany Yang wrote:
> > Sorry to resurrect this old thread, but I wanted to reply in case you
> > were still thinking about this for whatever reason. I was running into a  
> 
> Sorry for the late response. And thanks for resurrecting!
> 
> > I'm not sure how you set your config initially, but what jumps out at me
> > is that CONFIG_STACK_WARN=1024 even though
> > CONFIG_64BIT=y. CONFIG_STACK_WARN defaults to 2048 for 64-bit builds,  
> 
> Interesting. I really did "allnoconfig" and then turned on a few debug 
> options via "menuconfig", I did not set CONFIG_STACK_WARN manually. Thanks 
> for spotting this, I'll look into my cross-build routine if something 
> funny happens there.
> 
> > which is why other people don't seem to be running into this issue (at
> > least from glancing over the mailing list).
> > 
> > Obviously, this doesn't solve the actual problem, but from Liam's reply
> > further up in the thread, it looks like he's working on a fix, so now
> > you can keep your eye out for that!  
> 
> Yes, a proper fix would be great too.

Can't remember if I mentioned it before, but I suspect that letting
mas_commit_b_node() be inlined and then stopping both mas_rebalance()
and mas_split() being inlined into it (both of which are big and slow)
for all builds (not just KASAN ones) will reduce the overall stack slightly.

	David

> 
> cheers,
> Christian.