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@xxxxxxxxxxxxxx/
> > > 
> > > 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@xxxxxxxxxxxxxxx>

-- 
With Best Regards,
Andy Shevchenko