Re: [PATCH] crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y
From: Arnd Bergmann
Date: Mon Apr 13 2026 - 11:49:06 EST
On Wed, Apr 8, 2026, at 15:36, 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:
>> > 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.
Have you checked if the total call chain gets a lower stack usage this
way? Usually the high stack usage is a sign of absolutely awful
code generation when the compiler runs into a corner case that
spills variables onto the stack instead of keeping them in registers.
The question is whether the lower inline limit causes the compiler
to not get into this state at all and produce the expected object
code, or if it just ends up producing multiple functions that
stay under the limit individually but have the same problems with
stack usage and performance as before.
I think your patch can be merged either way, but it would be
good to describe what type of problem we are hitting here.
>> 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.
I ran into the same issue last year and worked around it by
turning off kasan for this file, which of course is problematic
for other reasons, and I never submitted my hack for inclusion:
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -176,6 +176,7 @@ obj-$(CONFIG_CRYPTO_USER_API_RNG) += algif_rng.o
obj-$(CONFIG_CRYPTO_USER_API_AEAD) += algif_aead.o
obj-$(CONFIG_CRYPTO_ZSTD) += zstd.o
obj-$(CONFIG_CRYPTO_ECC) += ecc.o
+KASAN_SANITIZE_ecc.o = n
obj-$(CONFIG_CRYPTO_ESSIV) += essiv.o
ecdh_generic-y += ecdh.o
In principle this could be done on a per-function basis.
Arnd