[PATCH v4 16/21] crypto/arm64: sm3 - Switch to 'ksimd' scoped guard API

[Ard Biesheuvel]

On Fri, 31 Oct 2025 at 14:52, Jonathan Cameron
<jonathan.cameron at huawei.com> wrote:
>
> On Fri, 31 Oct 2025 11:39:15 +0100
> Ard Biesheuvel <ardb+git at google.com> wrote:
>
> > From: Ard Biesheuvel <ardb at kernel.org>
> >
> > Switch to the more abstract 'scoped_ksimd()' API, which will be modified
> > in a future patch to transparently allocate a kernel mode FP/SIMD state
> > buffer on the stack, so that kernel mode FP/SIMD code remains
> > preemptible in principe, but without the memory overhead that adds 528
> > bytes to the size of struct task_struct.
> >
> > Reviewed-by: Eric Biggers <ebiggers at kernel.org>
> > Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> Hi Ard,
>
> Trivial comment inline.
>
> > ---
> >  arch/arm64/crypto/sm3-ce-glue.c   | 15 ++++++++-------
> >  arch/arm64/crypto/sm3-neon-glue.c | 16 ++++++----------
> >  2 files changed, 14 insertions(+), 17 deletions(-)
> >
> > diff --git a/arch/arm64/crypto/sm3-ce-glue.c b/arch/arm64/crypto/sm3-ce-glue.c
> > index eac6f5fa0abe..24c1fcfae072 100644
> > --- a/arch/arm64/crypto/sm3-ce-glue.c
> > +++ b/arch/arm64/crypto/sm3-ce-glue.c
> > @@ -5,7 +5,6 @@
> >   * Copyright (C) 2018 Linaro Ltd <ard.biesheuvel at linaro.org>
> >   */
> >
> > -#include <asm/neon.h>
> >  #include <crypto/internal/hash.h>
> >  #include <crypto/sm3.h>
> >  #include <crypto/sm3_base.h>
> > @@ -13,6 +12,8 @@
> >  #include <linux/kernel.h>
> >  #include <linux/module.h>
> >
> > +#include <asm/simd.h>
> > +
> >  MODULE_DESCRIPTION("SM3 secure hash using ARMv8 Crypto Extensions");
> >  MODULE_AUTHOR("Ard Biesheuvel <ard.biesheuvel at linaro.org>");
> >  MODULE_LICENSE("GPL v2");
> > @@ -25,18 +26,18 @@ static int sm3_ce_update(struct shash_desc *desc, const u8 *data,
> >  {
> >       int remain;
> >
> > -     kernel_neon_begin();
> > -     remain = sm3_base_do_update_blocks(desc, data, len, sm3_ce_transform);
> > -     kernel_neon_end();
> > +     scoped_ksimd() {
>
> Why does this get brackets unlike other cases?
>

No reason other than the fact that some time passed between writing
the other patches and these ones, and there is no functional
difference.