From: Herbert Xu <herbert@gondor.apana.org.au>
To: Lukas Wunner <lukas@wunner.de>
Cc: "David S. Miller" <davem@davemloft.net>,
Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Ignat Korchagin <ignat@linux.win>,
Stefan Berger <stefanb@linux.ibm.com>,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
kasan-dev@googlegroups.com,
Alexander Potapenko <glider@google.com>,
Andrey Konovalov <andreyknvl@gmail.com>,
Dmitry Vyukov <dvyukov@google.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Eric Biggers <ebiggers@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
David Laight <david.laight.linux@gmail.com>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH v2] crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y
Date: Fri, 15 May 2026 18:21:28 +0800 [thread overview]
Message-ID: <agbzqJUnMynmxSy3@gondor.apana.org.au> (raw)
In-Reply-To: <7e3d64a53efb28740b32d1f934e78c10086208ab.1778073318.git.lukas@wunner.de>
On Wed, May 06, 2026 at 03:27:49PM +0200, Lukas Wunner wrote:
> Andrew reports 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 aggressively inlines functions called by ecc_point_mult() (without
> there being any explicit inline declarations), which pushes stack usage
> close to the limit imposed by CONFIG_FRAME_WARN. allmodconfig implies
> CONFIG_KASAN_STACK=y, which increases the stack above that limit.
>
> In the bugzilla entry linked below, gcc maintainers explain that gcc
> estimates extra stack usage caused by inlining, but ASAN instrumentation
> is added in post-IPA passes and thus the inlining heuristics cannot
> account for it.
>
> It could be argued that -Werror=frame-larger-than=1280 instructs the
> compiler to avoid inlining beyond that limit lest the build breaks,
> which would imply gcc behaves incorrectly. But gcc maintainers reject
> this notion and believe that a warning switch should never affect code
> generation, even if it is promoted to an error.
>
> One way to unbreak the build is to limit inlining via -finline-limit=100
> or by explicitly declaring some functions noinline. However while it
> does keep stack usage of individual functions below the limit, *total*
> stack usage increases.
>
> A longterm solution is to refactor ecc.c for reduced stack usage. It
> currently performs ECC point multiplication with a Montgomery ladder
> which uses co-Z (conjugate) addition to trade off memory for speed.
> The algorithm is susceptible to timing attacks and needs to be replaced
> with a constant time Montgomery ladder, which should consume less memory
> and thus resolve the stack usage issue as a side effect.
>
> In the interim, raise the limit for ecc.c, as is already done for
> several other files in the source tree.
>
> Constrain to gcc because clang 19.1.7 does not exhibit the issue. It
> makes do with a 724 bytes stack frame even though it inlines almost the
> same functions as gcc.
>
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124949
> Reported-by: Andrew Morton <akpm@linux-foundation.org> # off-list
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> Changes v1 -> v2:
> * s/ARCH/CONFIG_ARM/, s/LLVM/CONFIG_CC_IS_GCC/ (Nathan)
> * Add link to gcc bugzilla entry
> * Rewrite commit message to include feedback provided by gcc maintainers
> and explain high stack usage with algorithm choice
>
> Link to v1:
> https://lore.kernel.org/r/abfaede9ab2e963d784fb70598ed74935f7f8d93.1775628469.git.lukas@wunner.de/
>
> crypto/Makefile | 5 +++++
> 1 file changed, 5 insertions(+)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
prev parent reply other threads:[~2026-05-15 10:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-06 13:27 [PATCH v2] crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y Lukas Wunner
2026-05-06 13:42 ` Andy Shevchenko
2026-05-06 13:56 ` Lukas Wunner
2026-05-06 14:03 ` Andy Shevchenko
2026-05-07 4:26 ` Herbert Xu
2026-05-07 9:26 ` Andy Shevchenko
2026-05-15 10:21 ` Herbert Xu [this message]
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=agbzqJUnMynmxSy3@gondor.apana.org.au \
--to=herbert@gondor.apana.org.au \
--cc=Jason@zx2c4.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=davem@davemloft.net \
--cc=david.laight.linux@gmail.com \
--cc=dvyukov@google.com \
--cc=ebiggers@kernel.org \
--cc=glider@google.com \
--cc=ignat@linux.win \
--cc=kasan-dev@googlegroups.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=nathan@kernel.org \
--cc=ryabinin.a.a@gmail.com \
--cc=stefanb@linux.ibm.com \
--cc=vincenzo.frascino@arm.com \
/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