From: "Arnd Bergmann" <arnd@arndb.de>
To: "Geert Uytterhoeven" <geert@linux-m68k.org>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>
Cc: "Kuninori Morimoto" <kuninori.morimoto.gx@renesas.com>,
"Russell King" <rmk+kernel@armlinux.org.uk>,
"Russell King" <linux@armlinux.org.uk>,
linux-arm-kernel@lists.infradead.org,
"Marek Vasut" <marek.vasut@mailbox.org>
Subject: Re: [issue report] ARM: compile error of frame size
Date: Wed, 15 Oct 2025 13:02:35 +0200 [thread overview]
Message-ID: <b3b13e21-ae54-4499-a569-0442bb9cfc8f@app.fastmail.com> (raw)
In-Reply-To: <CAMuHMdVqOR2kPy7V+N5oCFrKZA0R7JHC_+QsjFc5c43F1KFFiw@mail.gmail.com>
On Wed, Oct 15, 2025, at 12:07, Geert Uytterhoeven wrote:
> On Tue, 14 Oct 2025 at 18:53, Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
>> It is odd that this only shows up in certain cases though. Is there a
>> particular config option that is needed to cause the size to grow beyond
>> 1024?
>
> And of course there is: I still had a few 64-bit .configs that were
> derived from older 32-bit .configs, and thus still had
> CONFIG_FRAME_WARN=1024 :-(
> Changing them to match the recommended default fixed the issue:
>
> config FRAME_WARN
> int "Warn for stack frames larger than"
> ...
> default 1024 if !64BIT
> default 2048 if 64BIT
>
> Sorry for the noise...
I have a series that reduces the default warning limit for 64-bit,
but adds some slack for certain options such as KASAN that
are known to cause larger stacks throughout.
MIPS does have larger stack usage than most other architectures
here, and I do account for that with an architecture specific
base value as well, but in order to catch actual bugs in newly
written code, this has to be as small as possible.
What is the stack usage you observe in your configuration?
Arnd
next prev parent reply other threads:[~2025-10-15 11:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-18 2:09 [issue report] ARM: compile error of frame size Kuninori Morimoto
2025-07-28 14:56 ` Geert Uytterhoeven
2025-07-29 0:12 ` Kuninori Morimoto
2025-07-29 7:15 ` Geert Uytterhoeven
2025-07-29 7:27 ` Arnd Bergmann
2025-07-29 7:49 ` Geert Uytterhoeven
2025-10-14 14:47 ` Geert Uytterhoeven
2025-10-14 16:53 ` Liam R. Howlett
2025-10-15 9:26 ` Geert Uytterhoeven
2025-10-15 10:07 ` Geert Uytterhoeven
2025-10-15 11:02 ` Arnd Bergmann [this message]
2025-10-15 14:58 ` Geert Uytterhoeven
2025-10-15 15:17 ` Arnd Bergmann
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=b3b13e21-ae54-4499-a569-0442bb9cfc8f@app.fastmail.com \
--to=arnd@arndb.de \
--cc=Liam.Howlett@oracle.com \
--cc=geert@linux-m68k.org \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=marek.vasut@mailbox.org \
--cc=rmk+kernel@armlinux.org.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;
as well as URLs for NNTP newsgroup(s).