All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Christian Kujau <lists@nerdbynature.de>
Cc: linux-kernel@vger.kernel.org,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: maple_tree.c:3738:1: error: the frame size of 1040 bytes is larger than 1024 bytes
Date: Thu, 30 Oct 2025 16:51:37 +0000	[thread overview]
Message-ID: <20251030165137.56eb618f@pumpkin> (raw)
In-Reply-To: <bb105b91-1f11-0a2b-a666-6ee72f86d989@nerdbynature.de>

On Thu, 30 Oct 2025 15:48:30 +0100 (CET)
Christian Kujau <lists@nerdbynature.de> wrote:

> On Thu, 30 Oct 2025, David Laight wrote:
> > Does marking mas_wr_bnode() 'noinline' help?
> > Some functions are marked noinline for KASAN builds, the comment suggests
> > mas_wr_bnode() is one of them - but it isn't marked at all.  
> 
> Yes, I've seen that too. But adding noinline or noinline_for_kasan did not 
> help, compilation stopped with the same erro^W warning.

I've just looked at the disassembly of mas_wr_bnode() of a build where it
doesn't fail.
It is horrendous - best part of 4k code, the stack frame is 0x408.
Which means I must be building with a larger stack frame limit.
Is one of your debug options reducing it?

OTOH it looks as though the actual place to force a stack frame 'break' is to
stop mas_rebalance() and mas_split() being inlined into mas_commit_b_node().
(Probably instead of all the current noinline_for_kasan.)
Both those functions are large and don't have many parameters.

Oh, and the WARN_ON_ONCE() in there is all wrong.
A WARN_ON_ONCE(type != wr_split_store) after the call to mas_rebalance()
might make sense.

	David

> 
> diff --git a/lib/maple_tree.c b/lib/maple_tree.c
> index 39bb779cb311..90ec87d4d49d 100644
> --- a/lib/maple_tree.c
> +++ b/lib/maple_tree.c
> @@ -3727,7 +3727,7 @@ static inline void mas_wr_append(struct ma_wr_state 
> *wr_mas,
>   *
>   * This is where split, rebalance end up.
>   */
> -static void mas_wr_bnode(struct ma_wr_state *wr_mas)
> +static noinline_for_kasan void mas_wr_bnode(struct ma_wr_state *wr_mas)
>  {
>         struct maple_big_node b_node;
>  
> 
> Thanks,
> Christian.


  reply	other threads:[~2025-10-30 16:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-30 13:35 maple_tree.c:3738:1: error: the frame size of 1040 bytes is larger than 1024 bytes Christian Kujau
2025-10-30 14:34 ` David Laight
2025-10-30 14:48   ` Christian Kujau
2025-10-30 16:51     ` David Laight [this message]
2025-10-30 17:13       ` Christian Kujau
2025-10-30 17:25         ` Christian Kujau
2025-10-30 20:56         ` David Laight
2025-11-25 23:09         ` Tiffany Yang
2025-12-05  0:49           ` Christian Kujau
2025-12-05  9:05             ` David Laight

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=20251030165137.56eb618f@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=arnd@arndb.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lists@nerdbynature.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.