Re: [PATCH RT] arm*: disable NEON in kernel mode

[Dave Martin <Dave.Martin@arm.com>]

On Fri, Dec 01, 2017 at 06:08:28PM +0000, Russell King - ARM Linux wrote:
> On Fri, Dec 01, 2017 at 05:58:45PM +0000, Dave Martin wrote:
> > +1, at least for arm64.  I don't see a really compelling reason for
> > holding kernel-mode NEON around memory management now that we have a
> > strict save-once-restore-lazily model.
> > 
> > This may not work so well for arm though -- I haven't looked at that
> > code for a while.
> > 
> > 
> > If there is memory manamement in any core loop, you already lost
> > the performance battle, and an extra
> > kernel_neon_end()+kernel_neon_begin() may not be that catastrophic.
> 
> Remember that we don't permit context switches while kernel neon is
> in use on ARM - if there's any possibility of scheduling to occur,
> the get_cpu() in kernel_neon_begin() should trigger a schedule-while-
> atomic warning.

Agreed, and an arm64 the same is true.  (Actually softirq is disabled
too, for tortuous reasons involving SVE.)

On 2017-12-01 11:43:32 [+0100], To linux-rt-users@vger.kernel.org wrote:
> NEON in kernel mode is used by the crypto algorithms and raid6 code.
> While the raid6 code looks okay, the crypto algorithms do not: NEON
> is enabled on first invocation and may allocate/free/map memory before
> the NEON mode is disabled again.
> This needs to be changed until it can be enabled.
> On ARM NEON in kernel mode can be simply disabled. on ARM64 it needs to
> stay on due to possible EFI callbacks so here I disable each algorithm.

[...]

> diff --git a/arch/arm64/crypto/Kconfig b/arch/arm64/crypto/Kconfig
> index 70c517aa4501..2a5f05b5a19a 100644
> --- a/arch/arm64/crypto/Kconfig
> +++ b/arch/arm64/crypto/Kconfig
> @@ -19,19 +19,19 @@ config CRYPTO_SHA512_ARM64
>
>  config CRYPTO_SHA1_ARM64_CE
>     tristate "SHA-1 digest algorithm (ARMv8 Crypto Extensions)"
> -   depends on KERNEL_MODE_NEON
> +   depends on KERNEL_MODE_NEON && !PREEMPT_RT_BASE
>     select CRYPTO_HASH
>     select CRYPTO_SHA1

Sebastian, can you piont to where sha1 (say) hits this issue?
I wonder whether this is really a sign that some refactoring is needed.

Cheers
---Dave