[issue report] ARM: compile error of frame size

[issue report] ARM: compile error of frame size

[Kuninori Morimoto]

Hi ARM ML

In these days, I got a lot of compile error about frame size on ARM.
like below.

    ${linux}/lib/maple_tree.c:3818:1: error: the frame size of 1304 bytes is\
     larger than 1280 bytes [-Werror=frame-larger-than=]

I can avoid these errors by modifing like below
(The new size is unreliable)

	> grep CONFIG_FRAME_WARN .config
	CONFIG_FRAME_WARN=2040

	> git diff
	diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
	index d61369b1eabe..c5173bd82380 100644
	--- a/arch/arm/boot/compressed/Makefile
	+++ b/arch/arm/boot/compressed/Makefile
	@@ -80,7 +80,7 @@ libfdt_objs := fdt_rw.o fdt_ro.o fdt_wip.o fdt.o
 
	 ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
	 CFLAGS_REMOVE_atags_to_fdt.o += -Wframe-larger-than=${CONFIG_FRAME_WARN}
-	 CFLAGS_atags_to_fdt.o += -Wframe-larger-than=1280
+	 CFLAGS_atags_to_fdt.o += -Wframe-larger-than=2040
	 OBJS	+= $(libfdt_objs) atags_to_fdt.o
	 endif
	 ifeq ($(CONFIG_USE_OF),y)


Is it known issue ?


Thank you for your help !!

Best regards
---
Kuninori Morimoto

Re: [issue report] ARM: compile error of frame size

[Geert Uytterhoeven]

Hi Morimoto-san,

On Fri, 18 Jul 2025 at 04:09, Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
> In these days, I got a lot of compile error about frame size on ARM.
> like below.
>
>     ${linux}/lib/maple_tree.c:3818:1: error: the frame size of 1304 bytes is\
>      larger than 1280 bytes [-Werror=frame-larger-than=]
>
> I can avoid these errors by modifing like below
> (The new size is unreliable)
>
>         > grep CONFIG_FRAME_WARN .config
>         CONFIG_FRAME_WARN=2040
>
>         > git diff
>         diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
>         index d61369b1eabe..c5173bd82380 100644
>         --- a/arch/arm/boot/compressed/Makefile
>         +++ b/arch/arm/boot/compressed/Makefile
>         @@ -80,7 +80,7 @@ libfdt_objs := fdt_rw.o fdt_ro.o fdt_wip.o fdt.o
>
>          ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
>          CFLAGS_REMOVE_atags_to_fdt.o += -Wframe-larger-than=${CONFIG_FRAME_WARN}
> -        CFLAGS_atags_to_fdt.o += -Wframe-larger-than=1280
> +        CFLAGS_atags_to_fdt.o += -Wframe-larger-than=2040
>          OBJS   += $(libfdt_objs) atags_to_fdt.o
>          endif
>          ifeq ($(CONFIG_USE_OF),y)
>
>
> Is it known issue ?

Yes it is.  And it is hard to fix, according to the maple_tree maintainer:
https://lore.kernel.org/all/troejyyno7oiokx4njv7cbahwhkvkovlopj2igwlsexxqmrmaj@f3cjalwkpvf6

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [issue report] ARM: compile error of frame size

[Kuninori Morimoto]

Hi Geert
Cc Liam

Thank you for your feedback

> >         > grep CONFIG_FRAME_WARN .config
> >         CONFIG_FRAME_WARN=2040
> >
> >         > git diff
> >         diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> >         index d61369b1eabe..c5173bd82380 100644
> >         --- a/arch/arm/boot/compressed/Makefile
> >         +++ b/arch/arm/boot/compressed/Makefile
> >         @@ -80,7 +80,7 @@ libfdt_objs := fdt_rw.o fdt_ro.o fdt_wip.o fdt.o
> >
> >          ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
> >          CFLAGS_REMOVE_atags_to_fdt.o += -Wframe-larger-than=${CONFIG_FRAME_WARN}
> > -        CFLAGS_atags_to_fdt.o += -Wframe-larger-than=1280
> > +        CFLAGS_atags_to_fdt.o += -Wframe-larger-than=2040
> >          OBJS   += $(libfdt_objs) atags_to_fdt.o
> >          endif
> >          ifeq ($(CONFIG_USE_OF),y)
(snip)
> Yes it is.  And it is hard to fix, according to the maple_tree maintainer:

Hmm...
Actually I have tried to same solution (= remove or fix the big node), but
noticed there are many such code. My suggested was very simple solution
I guess, but I'm not sure detail of ARM limitation, and/or it can solve all
cases, etc...

But other CPU (like ARM64) doesn't have this issue, so we can follow same
way (= allow large frame) I guess.

Does ARM has some reason which can't use large frame ? If not, do you think
we can allow to use it on ARM ?

Thank you for your help !!

Best regards
---
Kuninori Morimoto

Re: [issue report] ARM: compile error of frame size

[Geert Uytterhoeven]

Hi Morimoto-san,

CC Arnd

On Tue, 29 Jul 2025 at 02:12, Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
> > >         > grep CONFIG_FRAME_WARN .config
> > >         CONFIG_FRAME_WARN=2040
> > >
> > >         > git diff
> > >         diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> > >         index d61369b1eabe..c5173bd82380 100644
> > >         --- a/arch/arm/boot/compressed/Makefile
> > >         +++ b/arch/arm/boot/compressed/Makefile
> > >         @@ -80,7 +80,7 @@ libfdt_objs := fdt_rw.o fdt_ro.o fdt_wip.o fdt.o
> > >
> > >          ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
> > >          CFLAGS_REMOVE_atags_to_fdt.o += -Wframe-larger-than=${CONFIG_FRAME_WARN}
> > > -        CFLAGS_atags_to_fdt.o += -Wframe-larger-than=1280
> > > +        CFLAGS_atags_to_fdt.o += -Wframe-larger-than=2040
> > >          OBJS   += $(libfdt_objs) atags_to_fdt.o
> > >          endif
> > >          ifeq ($(CONFIG_USE_OF),y)
> (snip)
> > Yes it is.  And it is hard to fix, according to the maple_tree maintainer:
>
> Hmm...
> Actually I have tried to same solution (= remove or fix the big node), but
> noticed there are many such code. My suggested was very simple solution
> I guess, but I'm not sure detail of ARM limitation, and/or it can solve all
> cases, etc...
>
> But other CPU (like ARM64) doesn't have this issue, so we can follow same
> way (= allow large frame) I guess.

I do see it in one my arm64 builds, it depends on your kernel config:

    lib/maple_tree.c: In function ‘mas_wr_spanning_store’:
    lib/maple_tree.c:3812:1: warning: the frame size of 1040 bytes is
larger than 1024 bytes [-Wframe-larger-than=] 3812 | }

I guess Arnd has seen it in his randconfig builds, too...

> Does ARM has some reason which can't use large frame ? If not, do you think
> we can allow to use it on ARM ?

(stacked) Large frames may cause kernel stack overflow.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [issue report] ARM: compile error of frame size

[Arnd Bergmann]

On Tue, Jul 29, 2025, at 09:15, Geert Uytterhoeven wrote:
> On Tue, 29 Jul 2025 at 02:12, Kuninori Morimoto
> <kuninori.morimoto.gx@renesas.com> wrote:
>> > >         > grep CONFIG_FRAME_WARN .config
>> > >         CONFIG_FRAME_WARN=2040
>> > >
>> > >         > git diff
>> > >         diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
>> > >         index d61369b1eabe..c5173bd82380 100644
>> > >         --- a/arch/arm/boot/compressed/Makefile
>> > >         +++ b/arch/arm/boot/compressed/Makefile
>> > >         @@ -80,7 +80,7 @@ libfdt_objs := fdt_rw.o fdt_ro.o fdt_wip.o fdt.o
>> > >
>> > >          ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
>> > >          CFLAGS_REMOVE_atags_to_fdt.o += -Wframe-larger-than=${CONFIG_FRAME_WARN}
>> > > -        CFLAGS_atags_to_fdt.o += -Wframe-larger-than=1280
>> > > +        CFLAGS_atags_to_fdt.o += -Wframe-larger-than=2040
>> > >          OBJS   += $(libfdt_objs) atags_to_fdt.o
>> > >          endif
>> > >          ifeq ($(CONFIG_USE_OF),y)
>> (snip)
>> > Yes it is.  And it is hard to fix, according to the maple_tree maintainer:
>>
>> Hmm...
>> Actually I have tried to same solution (= remove or fix the big node), but
>> noticed there are many such code. My suggested was very simple solution
>> I guess, but I'm not sure detail of ARM limitation, and/or it can solve all
>> cases, etc...
>>
>> But other CPU (like ARM64) doesn't have this issue, so we can follow same
>> way (= allow large frame) I guess.
>
> I do see it in one my arm64 builds, it depends on your kernel config:
>
>     lib/maple_tree.c: In function ‘mas_wr_spanning_store’:
>     lib/maple_tree.c:3812:1: warning: the frame size of 1040 bytes is
> larger than 1024 bytes [-Wframe-larger-than=] 3812 | }
>
> I guess Arnd has seen it in his randconfig builds, too...
>
>> Does ARM has some reason which can't use large frame ? If not, do you think
>> we can allow to use it on ARM ?
>
> (stacked) Large frames may cause kernel stack overflow.

The version below works around the warning for arm, arm64 and x86
on both gcc and clang.

IIRC there are still warnings on riscv and powerpc with this, at
least with clang.

To some degree, adding 'noinline' ends up just hiding the actual
stack usage, as it just gets split between more functions. On the
other hand there are cases where the inlining also lets the compiler
run into some corner case where it ends up spilling extra variables
to the stack, especially with sanitizers enabled.

    Arnd

diff --git a/lib/maple_tree.c b/lib/maple_tree.c
index b4ee2d29d7a9..622300b49afc 100644
--- a/lib/maple_tree.c
+++ b/lib/maple_tree.c
@@ -3569,7 +3569,7 @@ static bool mas_wr_walk(struct ma_wr_state *wr_mas)
 	return true;
 }
 
-static void mas_wr_walk_index(struct ma_wr_state *wr_mas)
+static noinline void mas_wr_walk_index(struct ma_wr_state *wr_mas)
 {
 	struct ma_state *mas = wr_mas->mas;
 
@@ -3730,10 +3730,9 @@ static inline void mas_new_root(struct ma_state *mas, void *entry)
  * span.
  * @wr_mas: The maple write state
  */
-static noinline void mas_wr_spanning_store(struct ma_wr_state *wr_mas)
+static noinline_for_kasan void _mas_wr_spanning_store(struct ma_wr_state *wr_mas, struct maple_big_node *b_node)
 {
 	struct maple_subtree_state mast;
-	struct maple_big_node b_node;
 	struct ma_state *mas;
 	unsigned char height;
 
@@ -3771,7 +3770,7 @@ static noinline void mas_wr_spanning_store(struct ma_wr_state *wr_mas)
 	 * store to ensure it's not NULL and to combine both the next node and
 	 * the node with the start together.
 	 */
-	r_mas = *mas;
+	memcpy(&r_mas, mas, sizeof(r_mas));
 	/* Avoid overflow, walk to next slot in the tree. */
 	if (r_mas.last + 1)
 		r_mas.last++;
@@ -3781,7 +3780,7 @@ static noinline void mas_wr_spanning_store(struct ma_wr_state *wr_mas)
 	r_mas.last = r_mas.index = mas->last;
 
 	/* Set up left side. */
-	l_mas = *mas;
+	memcpy(&l_mas, mas, sizeof(l_mas));
 	mas_wr_walk_index(&l_wr_mas);
 
 	if (!wr_mas->entry) {
@@ -3797,26 +3796,34 @@ static noinline void mas_wr_spanning_store(struct ma_wr_state *wr_mas)
 		return mas_new_root(mas, wr_mas->entry);
 	}
 
-	memset(&b_node, 0, sizeof(struct maple_big_node));
+	memset(b_node, 0, sizeof(struct maple_big_node));
 	/* Copy l_mas and store the value in b_node. */
-	mas_store_b_node(&l_wr_mas, &b_node, l_mas.end);
+	mas_store_b_node(&l_wr_mas, b_node, l_mas.end);
+
 	/* Copy r_mas into b_node if there is anything to copy. */
 	if (r_mas.max > r_mas.last)
 		mas_mab_cp(&r_mas, r_mas.offset, r_mas.end,
-			   &b_node, b_node.b_end + 1);
+			   b_node, b_node->b_end + 1);
 	else
-		b_node.b_end++;
+		b_node->b_end++;
 
 	/* Stop spanning searches by searching for just index. */
 	l_mas.index = l_mas.last = mas->index;
 
-	mast.bn = &b_node;
+	mast.bn = b_node;
 	mast.orig_l = &l_mas;
 	mast.orig_r = &r_mas;
+
 	/* Combine l_mas and r_mas and split them up evenly again. */
 	return mas_spanning_rebalance(mas, &mast, height + 1);
 }
 
+static noinline void mas_wr_spanning_store(struct ma_wr_state *wr_mas)
+{
+	struct maple_big_node b_node;
+
+	_mas_wr_spanning_store(wr_mas, &b_node);
+}
 /*
  * mas_wr_node_store() - Attempt to store the value in a node
  * @wr_mas: The maple write state
@@ -4069,7 +4076,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 void mas_wr_bnode(struct ma_wr_state *wr_mas)
 {
 	struct maple_big_node b_node;
 

Re: [issue report] ARM: compile error of frame size

[Geert Uytterhoeven]

Hi Arnd,

On Tue, 29 Jul 2025 at 09:27, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tue, Jul 29, 2025, at 09:15, Geert Uytterhoeven wrote:
> > On Tue, 29 Jul 2025 at 02:12, Kuninori Morimoto
> > <kuninori.morimoto.gx@renesas.com> wrote:
> >> > >         > grep CONFIG_FRAME_WARN .config
> >> > >         CONFIG_FRAME_WARN=2040
> >> > >
> >> > >         > git diff
> >> > >         diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> >> > >         index d61369b1eabe..c5173bd82380 100644
> >> > >         --- a/arch/arm/boot/compressed/Makefile
> >> > >         +++ b/arch/arm/boot/compressed/Makefile
> >> > >         @@ -80,7 +80,7 @@ libfdt_objs := fdt_rw.o fdt_ro.o fdt_wip.o fdt.o
> >> > >
> >> > >          ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
> >> > >          CFLAGS_REMOVE_atags_to_fdt.o += -Wframe-larger-than=${CONFIG_FRAME_WARN}
> >> > > -        CFLAGS_atags_to_fdt.o += -Wframe-larger-than=1280
> >> > > +        CFLAGS_atags_to_fdt.o += -Wframe-larger-than=2040
> >> > >          OBJS   += $(libfdt_objs) atags_to_fdt.o
> >> > >          endif
> >> > >          ifeq ($(CONFIG_USE_OF),y)
> >> (snip)
> >> > Yes it is.  And it is hard to fix, according to the maple_tree maintainer:
> >>
> >> Hmm...
> >> Actually I have tried to same solution (= remove or fix the big node), but
> >> noticed there are many such code. My suggested was very simple solution
> >> I guess, but I'm not sure detail of ARM limitation, and/or it can solve all
> >> cases, etc...
> >>
> >> But other CPU (like ARM64) doesn't have this issue, so we can follow same
> >> way (= allow large frame) I guess.
> >
> > I do see it in one my arm64 builds, it depends on your kernel config:
> >
> >     lib/maple_tree.c: In function ‘mas_wr_spanning_store’:
> >     lib/maple_tree.c:3812:1: warning: the frame size of 1040 bytes is
> > larger than 1024 bytes [-Wframe-larger-than=] 3812 | }
> >
> > I guess Arnd has seen it in his randconfig builds, too...
> >
> >> Does ARM has some reason which can't use large frame ? If not, do you think
> >> we can allow to use it on ARM ?
> >
> > (stacked) Large frames may cause kernel stack overflow.
>
> The version below works around the warning for arm, arm64 and x86
> on both gcc and clang.

Thanks, that indeed works for my arm64 config that triggered it before.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [issue report] ARM: compile error of frame size

[Geert Uytterhoeven]

Hi Arnd,

On Tue, 29 Jul 2025 at 09:49, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, 29 Jul 2025 at 09:27, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tue, Jul 29, 2025, at 09:15, Geert Uytterhoeven wrote:
> > > On Tue, 29 Jul 2025 at 02:12, Kuninori Morimoto
> > > <kuninori.morimoto.gx@renesas.com> wrote:
> > >> > >         > grep CONFIG_FRAME_WARN .config
> > >> > >         CONFIG_FRAME_WARN=2040
> > >> > >
> > >> > >         > git diff
> > >> > >         diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> > >> > >         index d61369b1eabe..c5173bd82380 100644
> > >> > >         --- a/arch/arm/boot/compressed/Makefile
> > >> > >         +++ b/arch/arm/boot/compressed/Makefile
> > >> > >         @@ -80,7 +80,7 @@ libfdt_objs := fdt_rw.o fdt_ro.o fdt_wip.o fdt.o
> > >> > >
> > >> > >          ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
> > >> > >          CFLAGS_REMOVE_atags_to_fdt.o += -Wframe-larger-than=${CONFIG_FRAME_WARN}
> > >> > > -        CFLAGS_atags_to_fdt.o += -Wframe-larger-than=1280
> > >> > > +        CFLAGS_atags_to_fdt.o += -Wframe-larger-than=2040
> > >> > >          OBJS   += $(libfdt_objs) atags_to_fdt.o
> > >> > >          endif
> > >> > >          ifeq ($(CONFIG_USE_OF),y)
> > >> (snip)
> > >> > Yes it is.  And it is hard to fix, according to the maple_tree maintainer:
> > >>
> > >> Hmm...
> > >> Actually I have tried to same solution (= remove or fix the big node), but
> > >> noticed there are many such code. My suggested was very simple solution
> > >> I guess, but I'm not sure detail of ARM limitation, and/or it can solve all
> > >> cases, etc...
> > >>
> > >> But other CPU (like ARM64) doesn't have this issue, so we can follow same
> > >> way (= allow large frame) I guess.
> > >
> > > I do see it in one my arm64 builds, it depends on your kernel config:
> > >
> > >     lib/maple_tree.c: In function ‘mas_wr_spanning_store’:
> > >     lib/maple_tree.c:3812:1: warning: the frame size of 1040 bytes is
> > > larger than 1024 bytes [-Wframe-larger-than=] 3812 | }
> > >
> > > I guess Arnd has seen it in his randconfig builds, too...
> > >
> > >> Does ARM has some reason which can't use large frame ? If not, do you think
> > >> we can allow to use it on ARM ?
> > >
> > > (stacked) Large frames may cause kernel stack overflow.
> >
> > The version below works around the warning for arm, arm64 and x86
> > on both gcc and clang.
>
> Thanks, that indeed works for my arm64 config that triggered it before.

Unfortunately it no longer helps for my rbxt4927 build...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [issue report] ARM: compile error of frame size

[Liam R. Howlett]

* Geert Uytterhoeven <geert@linux-m68k.org> [251014 10:47]:
> Hi Arnd,
> 
> On Tue, 29 Jul 2025 at 09:49, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, 29 Jul 2025 at 09:27, Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Tue, Jul 29, 2025, at 09:15, Geert Uytterhoeven wrote:
> > > > On Tue, 29 Jul 2025 at 02:12, Kuninori Morimoto
> > > > <kuninori.morimoto.gx@renesas.com> wrote:
> > > >> > >         > grep CONFIG_FRAME_WARN .config
> > > >> > >         CONFIG_FRAME_WARN=2040
> > > >> > >
> > > >> > >         > git diff
> > > >> > >         diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> > > >> > >         index d61369b1eabe..c5173bd82380 100644
> > > >> > >         --- a/arch/arm/boot/compressed/Makefile
> > > >> > >         +++ b/arch/arm/boot/compressed/Makefile
> > > >> > >         @@ -80,7 +80,7 @@ libfdt_objs := fdt_rw.o fdt_ro.o fdt_wip.o fdt.o
> > > >> > >
> > > >> > >          ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
> > > >> > >          CFLAGS_REMOVE_atags_to_fdt.o += -Wframe-larger-than=${CONFIG_FRAME_WARN}
> > > >> > > -        CFLAGS_atags_to_fdt.o += -Wframe-larger-than=1280
> > > >> > > +        CFLAGS_atags_to_fdt.o += -Wframe-larger-than=2040
> > > >> > >          OBJS   += $(libfdt_objs) atags_to_fdt.o
> > > >> > >          endif
> > > >> > >          ifeq ($(CONFIG_USE_OF),y)
> > > >> (snip)
> > > >> > Yes it is.  And it is hard to fix, according to the maple_tree maintainer:
> > > >>
> > > >> Hmm...
> > > >> Actually I have tried to same solution (= remove or fix the big node), but
> > > >> noticed there are many such code. My suggested was very simple solution
> > > >> I guess, but I'm not sure detail of ARM limitation, and/or it can solve all
> > > >> cases, etc...
> > > >>
> > > >> But other CPU (like ARM64) doesn't have this issue, so we can follow same
> > > >> way (= allow large frame) I guess.
> > > >
> > > > I do see it in one my arm64 builds, it depends on your kernel config:
> > > >
> > > >     lib/maple_tree.c: In function ‘mas_wr_spanning_store’:
> > > >     lib/maple_tree.c:3812:1: warning: the frame size of 1040 bytes is
> > > > larger than 1024 bytes [-Wframe-larger-than=] 3812 | }
> > > >
> > > > I guess Arnd has seen it in his randconfig builds, too...
> > > >
> > > >> Does ARM has some reason which can't use large frame ? If not, do you think
> > > >> we can allow to use it on ARM ?
> > > >
> > > > (stacked) Large frames may cause kernel stack overflow.
> > >
> > > The version below works around the warning for arm, arm64 and x86
> > > on both gcc and clang.
> >
> > Thanks, that indeed works for my arm64 config that triggered it before.
> 
> Unfortunately it no longer helps for my rbxt4927 build...
> 

I've been working on fixing this for a while and am approaching a point
where I'll share my solution.

The change is non-trivial and is required for expanding node type
support.  But with the amount of change this introduces, I do not want
to backport the patch set, if possible.

Considering how close we are here (16 bytes), it may be better to find
another solution to avoid the particular troubled builds.

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?

Thanks,
Liam

Re: [issue report] ARM: compile error of frame size

[Geert Uytterhoeven]

Hi Liam,

On Tue, 14 Oct 2025 at 18:53, Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> * Geert Uytterhoeven <geert@linux-m68k.org> [251014 10:47]:
> > On Tue, 29 Jul 2025 at 09:49, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Tue, 29 Jul 2025 at 09:27, Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Tue, Jul 29, 2025, at 09:15, Geert Uytterhoeven wrote:
> > > > > On Tue, 29 Jul 2025 at 02:12, Kuninori Morimoto
> > > > > <kuninori.morimoto.gx@renesas.com> wrote:
> > > > >> > >         > grep CONFIG_FRAME_WARN .config
> > > > >> > >         CONFIG_FRAME_WARN=2040
> > > > >> > >
> > > > >> > >         > git diff
> > > > >> > >         diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> > > > >> > >         index d61369b1eabe..c5173bd82380 100644
> > > > >> > >         --- a/arch/arm/boot/compressed/Makefile
> > > > >> > >         +++ b/arch/arm/boot/compressed/Makefile
> > > > >> > >         @@ -80,7 +80,7 @@ libfdt_objs := fdt_rw.o fdt_ro.o fdt_wip.o fdt.o
> > > > >> > >
> > > > >> > >          ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
> > > > >> > >          CFLAGS_REMOVE_atags_to_fdt.o += -Wframe-larger-than=${CONFIG_FRAME_WARN}
> > > > >> > > -        CFLAGS_atags_to_fdt.o += -Wframe-larger-than=1280
> > > > >> > > +        CFLAGS_atags_to_fdt.o += -Wframe-larger-than=2040
> > > > >> > >          OBJS   += $(libfdt_objs) atags_to_fdt.o
> > > > >> > >          endif
> > > > >> > >          ifeq ($(CONFIG_USE_OF),y)
> > > > >> (snip)
> > > > >> > Yes it is.  And it is hard to fix, according to the maple_tree maintainer:
> > > > >>
> > > > >> Hmm...
> > > > >> Actually I have tried to same solution (= remove or fix the big node), but
> > > > >> noticed there are many such code. My suggested was very simple solution
> > > > >> I guess, but I'm not sure detail of ARM limitation, and/or it can solve all
> > > > >> cases, etc...
> > > > >>
> > > > >> But other CPU (like ARM64) doesn't have this issue, so we can follow same
> > > > >> way (= allow large frame) I guess.
> > > > >
> > > > > I do see it in one my arm64 builds, it depends on your kernel config:
> > > > >
> > > > >     lib/maple_tree.c: In function ‘mas_wr_spanning_store’:
> > > > >     lib/maple_tree.c:3812:1: warning: the frame size of 1040 bytes is
> > > > > larger than 1024 bytes [-Wframe-larger-than=] 3812 | }
> > > > >
> > > > > I guess Arnd has seen it in his randconfig builds, too...
> > > > >
> > > > >> Does ARM has some reason which can't use large frame ? If not, do you think
> > > > >> we can allow to use it on ARM ?
> > > > >
> > > > > (stacked) Large frames may cause kernel stack overflow.
> > > >
> > > > The version below works around the warning for arm, arm64 and x86
> > > > on both gcc and clang.
> > >
> > > Thanks, that indeed works for my arm64 config that triggered it before.
> >
> > Unfortunately it no longer helps for my rbxt4927 build...
>
> I've been working on fixing this for a while and am approaching a point
> where I'll share my solution.
>
> The change is non-trivial and is required for expanding node type
> support.  But with the amount of change this introduces, I do not want
> to backport the patch set, if possible.
>
> Considering how close we are here (16 bytes), it may be better to find
> another solution to avoid the particular troubled builds.
>
> 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?

I don't know.  I bisected the issue in my rbxt4927 (MIPS) build to commit
6bf377b06c08049d ("maple_tree: Add single node allocation support to
maple state") in v6.18-rc1.

Reverting the s/inline/__always_inline/ in that commit does not fix
the issue, but

    --- a/lib/maple_tree.c
    +++ b/lib/maple_tree.c
    @@ -159,7 +159,7 @@ struct maple_subtree_state {
            struct maple_big_node *bn;
     };

    -#ifdef CONFIG_KASAN_STACK
    +#if 1 //def CONFIG_KASAN_STACK
     /* Prevent mas_wr_bnode() from exceeding the stack frame limit */
     #define noinline_for_kasan noinline_for_stack
     #else

does.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [issue report] ARM: compile error of frame size

[Geert Uytterhoeven]

Hi Liam,

On Tue, 14 Oct 2025 at 18:53, Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> * Geert Uytterhoeven <geert@linux-m68k.org> [251014 10:47]:
> > On Tue, 29 Jul 2025 at 09:49, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Tue, 29 Jul 2025 at 09:27, Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Tue, Jul 29, 2025, at 09:15, Geert Uytterhoeven wrote:
> > > > > On Tue, 29 Jul 2025 at 02:12, Kuninori Morimoto
> > > > > <kuninori.morimoto.gx@renesas.com> wrote:
> > > > >> > >         > grep CONFIG_FRAME_WARN .config
> > > > >> > >         CONFIG_FRAME_WARN=2040
> > > > >> > >
> > > > >> > >         > git diff
> > > > >> > >         diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> > > > >> > >         index d61369b1eabe..c5173bd82380 100644
> > > > >> > >         --- a/arch/arm/boot/compressed/Makefile
> > > > >> > >         +++ b/arch/arm/boot/compressed/Makefile
> > > > >> > >         @@ -80,7 +80,7 @@ libfdt_objs := fdt_rw.o fdt_ro.o fdt_wip.o fdt.o
> > > > >> > >
> > > > >> > >          ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
> > > > >> > >          CFLAGS_REMOVE_atags_to_fdt.o += -Wframe-larger-than=${CONFIG_FRAME_WARN}
> > > > >> > > -        CFLAGS_atags_to_fdt.o += -Wframe-larger-than=1280
> > > > >> > > +        CFLAGS_atags_to_fdt.o += -Wframe-larger-than=2040
> > > > >> > >          OBJS   += $(libfdt_objs) atags_to_fdt.o
> > > > >> > >          endif
> > > > >> > >          ifeq ($(CONFIG_USE_OF),y)
> > > > >> (snip)
> > > > >> > Yes it is.  And it is hard to fix, according to the maple_tree maintainer:
> > > > >>
> > > > >> Hmm...
> > > > >> Actually I have tried to same solution (= remove or fix the big node), but
> > > > >> noticed there are many such code. My suggested was very simple solution
> > > > >> I guess, but I'm not sure detail of ARM limitation, and/or it can solve all
> > > > >> cases, etc...
> > > > >>
> > > > >> But other CPU (like ARM64) doesn't have this issue, so we can follow same
> > > > >> way (= allow large frame) I guess.
> > > > >
> > > > > I do see it in one my arm64 builds, it depends on your kernel config:
> > > > >
> > > > >     lib/maple_tree.c: In function ‘mas_wr_spanning_store’:
> > > > >     lib/maple_tree.c:3812:1: warning: the frame size of 1040 bytes is
> > > > > larger than 1024 bytes [-Wframe-larger-than=] 3812 | }
> > > > >
> > > > > I guess Arnd has seen it in his randconfig builds, too...
> > > > >
> > > > >> Does ARM has some reason which can't use large frame ? If not, do you think
> > > > >> we can allow to use it on ARM ?
> > > > >
> > > > > (stacked) Large frames may cause kernel stack overflow.
> > > >
> > > > The version below works around the warning for arm, arm64 and x86
> > > > on both gcc and clang.
> > >
> > > Thanks, that indeed works for my arm64 config that triggered it before.
> >
> > Unfortunately it no longer helps for my rbxt4927 build...
> >
>
> I've been working on fixing this for a while and am approaching a point
> where I'll share my solution.
>
> The change is non-trivial and is required for expanding node type
> support.  But with the amount of change this introduces, I do not want
> to backport the patch set, if possible.
>
> Considering how close we are here (16 bytes), it may be better to find
> another solution to avoid the particular troubled builds.
>
> 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...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [issue report] ARM: compile error of frame size

[Arnd Bergmann]

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

Re: [issue report] ARM: compile error of frame size

[Geert Uytterhoeven]

Hi Arnd,

On Wed, 15 Oct 2025 at 13:03, Arnd Bergmann <arnd@arndb.de> wrote:
> 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?

1056 bytes on arm64, 1040 on mips64, i.e. just above the "32-bit"
default of 1024, but far from the "64-bit" default of 2048.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [issue report] ARM: compile error of frame size

[Arnd Bergmann]

On Wed, Oct 15, 2025, at 16:58, Geert Uytterhoeven wrote:
> On Wed, 15 Oct 2025 at 13:03, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wed, Oct 15, 2025, at 12:07, Geert Uytterhoeven wrote:
>>
>> 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?
>
> 1056 bytes on arm64, 1040 on mips64, i.e. just above the "32-bit"
> default of 1024, but far from the "64-bit" default of 2048.
>

Ok, great, I'm not worried then.

     Arnd