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

[Lukas Wunner <lukas@wunner.de>]

On Mon, Apr 13, 2026 at 10:32:24PM +0200, Arnd Bergmann wrote:
> On Mon, Apr 13, 2026, at 21:46, Lukas Wunner wrote:
> > On Mon, Apr 13, 2026 at 05:42:39PM +0200, Arnd Bergmann wrote:
> > > On Wed, Apr 8, 2026, at 15:36, Lukas Wunner wrote:
> > Attached please find the Assembler output created by gcc -save-temps,
> > both the original version and the one with limited inlining.
> >
> > The former requires a 1360 bytes stack frame, the latter 1232 bytes.
> > E.g. xycz_initial_double() is not inlined into ecc_point_mult(),
> > together with all its recursive baggage, so the latter version
> > contains two branch instructions to that function which the former
> > (original) version does not contain.
> 
> So it indeed appears that the problem does not go away but only
> stays below the arbitrary threshold of 1280 bytes (which was
> recently raised). I would not trust that to actually be the
> case across all architectures then, as there are some targets
> like mips or parisc tend to use even more stack space than
> arm. With your current patch, that means there is a good chance
> the problem will come back later.

The only 32-bit architectures with HAVE_ARCH_KASAN are:
arm powerpc xtensa

I've cross-compiled ecc.o successfully in an allmodconfig build for
powerpc and xtensa, so arm seems to be the only architecture affected
by the large stack frame issue.

Maybe mips and parisc will see the issue as well but they'd have to
support KASAN first.

The problem is that gcc *knows* that it should warn when the stack
goes above CONFIG_FRAME_WARN and that warning is even promoted to
an error, but gcc happily keeps inlining stuff and goes beyond that
limit.  My expectation is it should stop inlining before that happens.
clang doesn't have the same problem.

Completely disabling KASAN for this file doesn't seem like a good option
as this is security-relevant code.  On the other hand disabling inlining
for this file isn't great either because I recall Google is dogfooding
KASAN on internally used phones, I imagine it would ruin performance
for such use cases (granted those are likely arm64 devices).

*Limiting* inlining strikes a middle ground between those two extremes.

And I don't want to annotate individual functions as noinline only
because gcc does stupid things on a single architecture.

Thanks,

Lukas