linux-kernel - Re: riscv gcc-13 allyesconfig error the frame size of 2064 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]

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: <20250525184757.23c5e5d2@pumpkin>
Date: Sun, 25 May 2025 18:47:57 +0100
From: David Laight <david.laight.linux@...il.com>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: Arnd Bergmann <arnd@...db.de>, Naresh Kamboju
 <naresh.kamboju@...aro.org>, linux-bcache@...r.kernel.org, open list
 <linux-kernel@...r.kernel.org>, lkft-triage@...ts.linaro.org, Linux
 Regressions <regressions@...ts.linux.dev>, Dan Carpenter
 <dan.carpenter@...aro.org>, Anders Roxell <anders.roxell@...aro.org>,
 Steven Rostedt <rostedt@...dmis.org>
Subject: Re: riscv gcc-13 allyesconfig error the frame size of 2064 bytes is
 larger than 2048 bytes [-Werror=frame-larger-than=]

On Sun, 25 May 2025 13:36:16 -0400
Kent Overstreet <kent.overstreet@...ux.dev> wrote:

> +cc Steve
...
> > I've a cunning plan to do a proper static analysis of stack usage.
> > It is a 'simple' matter of getting objtool to output all calls with
> > the stack offset.
> > Indirect calls need the function hashes from fine-ibt, but also need
> > clang to support 'hash seeds' to disambiguate all the void (*)(void *)
> > functions.
> > That'll first barf at all recursion, and then, I expect, show a massive
> > stack use inside snprintf() in some error path.  
> 
> I suspect recursion will make the results you get with that approach
> useless.

Recursion is an issue, but the kernel really doesn't support recursion.
So you actually want to know the possible recursion loops anyway.
I suspect (hope) most will be the 'recurses only once' type.
If not they need some other bound.

> We already have "trace max stack", but that only checks at process exit,
> so it doesn't tell you much.
> 
> We could do better with tracing - just inject a trampoline that checks
> the current stack usage against the maximum stack usage we've seen, and
> emits a trace event with a stack trace if it's greater.

Both those only tells you the stack you've used.
The static analysis will show you the stack 'you might use'.
Which is really much more important.

I did this for an embedded system a long time ago.
The outcome was that we didn't have enough memory to allocate the
'worst case' stacks!

	David