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

["Arnd Bergmann" <arnd@arndb.de>]

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.

Thanks!

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.

> At the beginning of the function, it looks like the same register values
> are stored to multiple locations on the stack.  I assume that's what you
> mean by awful code generation?  This odd behavior seems more subdued in
> the version with limited inlining.

Right. As far as I can tell, the source code is heavily optimized
for performance, but with the sanitizer active this would likely
be several times slower, both from the actual sanitizing and
from the register spilling. I can see how the use of 'u64'
arrays makes this harder for a 32-bit target with limited
available registers.

     Arnd