[PATCH] crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y

[PATCH] crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y

[Lukas Wunner]

Andrew reports the following build breakage of arm allmodconfig,
reproducible with gcc 14.2.0 and 15.2.0:

  crypto/ecc.c: In function 'ecc_point_mult':
  crypto/ecc.c:1380:1: error: the frame size of 1360 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]

gcc excessively inlines functions called by ecc_point_mult() (without
there being any explicit inline declarations) and doesn't seem smart
enough to stay below CONFIG_FRAME_WARN.

clang does not exhibit the issue.

The issue only occurs with CONFIG_KASAN_STACK=y because it enlarges the
frame size.  This has been a controversial topic a couple of times:

https://lore.kernel.org/r/CAK8P3a3_Tdc-XVPXrJ69j3S9048uzmVJGrNcvi0T6yr6OrHkPw@mail.gmail.com/

Prevent gcc from going overboard with inlining to unbreak the build.
The maximum inline limit to avoid the error is 101.  Use 100 to get a
nice round number per Andrew's preference.

Reported-by: Andrew Morton <akpm@linux-foundation.org> # off-list
Signed-off-by: Lukas Wunner <lukas@wunner.de>
---
 crypto/Makefile | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/crypto/Makefile b/crypto/Makefile
index 04e269117589..b3ac7f29153e 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -181,6 +181,11 @@ obj-$(CONFIG_CRYPTO_ZSTD) += zstd.o
 obj-$(CONFIG_CRYPTO_ECC) += ecc.o
 obj-$(CONFIG_CRYPTO_ESSIV) += essiv.o
 
+# Avoid exceeding stack frame due to excessive gcc inlining in ecc_point_mult()
+ifeq ($(ARCH)$(CONFIG_KASAN_STACK)$(LLVM),army)
+CFLAGS_ecc.o += $(call cc-option,-finline-limit=100)
+endif
+
 ecdh_generic-y += ecdh.o
 ecdh_generic-y += ecdh_helper.o
 obj-$(CONFIG_CRYPTO_ECDH) += ecdh_generic.o
-- 
2.51.0

Re: [PATCH] crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y

[Andy Shevchenko]

On Wed, Apr 08, 2026 at 08:15:49AM +0200, Lukas Wunner wrote:
> Andrew reports the following build breakage of arm allmodconfig,
> reproducible with gcc 14.2.0 and 15.2.0:
> 
>   crypto/ecc.c: In function 'ecc_point_mult':
>   crypto/ecc.c:1380:1: error: the frame size of 1360 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
> 
> gcc excessively inlines functions called by ecc_point_mult() (without
> there being any explicit inline declarations) and doesn't seem smart
> enough to stay below CONFIG_FRAME_WARN.
> 
> clang does not exhibit the issue.
> 
> The issue only occurs with CONFIG_KASAN_STACK=y because it enlarges the
> frame size.  This has been a controversial topic a couple of times:
> 
> https://lore.kernel.org/r/CAK8P3a3_Tdc-XVPXrJ69j3S9048uzmVJGrNcvi0T6yr6OrHkPw@mail.gmail.com/
> 
> Prevent gcc from going overboard with inlining to unbreak the build.
> The maximum inline limit to avoid the error is 101.  Use 100 to get a
> nice round number per Andrew's preference.

I think this is not the best solution. We still can refactor the code and avoid
being dependant to the (useful) kernel options.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y

[Lukas Wunner]

On Wed, Apr 08, 2026 at 02:31:21PM +0300, Andy Shevchenko wrote:
> On Wed, Apr 08, 2026 at 08:15:49AM +0200, Lukas Wunner wrote:
> > Andrew reports the following build breakage of arm allmodconfig,
> > reproducible with gcc 14.2.0 and 15.2.0:
> > 
> >   crypto/ecc.c: In function 'ecc_point_mult':
> >   crypto/ecc.c:1380:1: error: the frame size of 1360 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
> > 
> > gcc excessively inlines functions called by ecc_point_mult() (without
> > there being any explicit inline declarations) and doesn't seem smart
> > enough to stay below CONFIG_FRAME_WARN.
> > 
> > clang does not exhibit the issue.
> > 
> > The issue only occurs with CONFIG_KASAN_STACK=y because it enlarges the
> > frame size.  This has been a controversial topic a couple of times:
> > 
> > https://lore.kernel.org/r/CAK8P3a3_Tdc-XVPXrJ69j3S9048uzmVJGrNcvi0T6yr6OrHkPw@mail.gmail.com/
> > 
> > Prevent gcc from going overboard with inlining to unbreak the build.
> > The maximum inline limit to avoid the error is 101.  Use 100 to get a
> > nice round number per Andrew's preference.
> 
> I think this is not the best solution. We still can refactor the code
> and avoid being dependant to the (useful) kernel options.

Refactor how?  Mark functions "noinline"?  That may negatively impact
performance for everyone.

Note that this is a different kind of stack frame exhaustion than the one
in drivers/mtd/chips/cfi_cmdset_0001.c:do_write_buffer():  The latter
is a single function with lots of large local variables, whereas
ecc_point_mult() itself has a reasonable number of variables on the stack,
but gcc inlines numerous function calls that each increase the stack frame.

And gcc isn't smart enough to stop inlining when it reaches the maximum
stack frame size allowed by CONFIG_FRAME_WARN.

It's apparently a compiler bug.  Why should we work around compiler bugs
by refactoring the code?  The proposed patch instructs gcc to limit
inlining and we can easily remove that once the bug is fixed.

As Arnd explains in the above-linked message, stack frame exhaustion
in crypto/ tends to be caused by compiler bugs.  There are already two
other workarounds for compiler bugs in crypto/Makefile, one for wp512.o
and another for serpent_generic.o.  Amending CFLAGS is how we've dealt
with these issues in the past, not by refactoring code.

Thanks,

Lukas

Re: [PATCH] crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y

[Andy Shevchenko]

On Wed, Apr 08, 2026 at 03:36:47PM +0200, Lukas Wunner wrote:
> On Wed, Apr 08, 2026 at 02:31:21PM +0300, Andy Shevchenko wrote:
> > On Wed, Apr 08, 2026 at 08:15:49AM +0200, Lukas Wunner wrote:
> > > Andrew reports the following build breakage of arm allmodconfig,
> > > reproducible with gcc 14.2.0 and 15.2.0:
> > > 
> > >   crypto/ecc.c: In function 'ecc_point_mult':
> > >   crypto/ecc.c:1380:1: error: the frame size of 1360 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
> > > 
> > > gcc excessively inlines functions called by ecc_point_mult() (without
> > > there being any explicit inline declarations) and doesn't seem smart
> > > enough to stay below CONFIG_FRAME_WARN.
> > > 
> > > clang does not exhibit the issue.
> > > 
> > > The issue only occurs with CONFIG_KASAN_STACK=y because it enlarges the
> > > frame size.  This has been a controversial topic a couple of times:
> > > 
> > > https://lore.kernel.org/r/CAK8P3a3_Tdc-XVPXrJ69j3S9048uzmVJGrNcvi0T6yr6OrHkPw@mail.gmail.com/
> > > 
> > > Prevent gcc from going overboard with inlining to unbreak the build.
> > > The maximum inline limit to avoid the error is 101.  Use 100 to get a
> > > nice round number per Andrew's preference.
> > 
> > I think this is not the best solution. We still can refactor the code
> > and avoid being dependant to the (useful) kernel options.

> Refactor how?  Mark functions "noinline"?  That may negatively impact
> performance for everyone.
> 
> Note that this is a different kind of stack frame exhaustion than the one
> in drivers/mtd/chips/cfi_cmdset_0001.c:do_write_buffer():  The latter
> is a single function with lots of large local variables, whereas
> ecc_point_mult() itself has a reasonable number of variables on the stack,
> but gcc inlines numerous function calls that each increase the stack frame.

Ah, that makes the difference, thanks for elaborating!

> And gcc isn't smart enough to stop inlining when it reaches the maximum
> stack frame size allowed by CONFIG_FRAME_WARN.
> 
> It's apparently a compiler bug.  Why should we work around compiler bugs
> by refactoring the code?  The proposed patch instructs gcc to limit
> inlining and we can easily remove that once the bug is fixed.
> 
> As Arnd explains in the above-linked message, stack frame exhaustion
> in crypto/ tends to be caused by compiler bugs.  There are already two
> other workarounds for compiler bugs in crypto/Makefile, one for wp512.o
> and another for serpent_generic.o.  Amending CFLAGS is how we've dealt
> with these issues in the past, not by refactoring code.

Yeah, that's the way we may deal with the issue.

Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

-- 
With Best Regards,
Andy Shevchenko