lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 19 Dec 2020 13:04:33 +1100
From:   Herbert Xu <>
To:     Ard Biesheuvel <>
Cc:,,, Dave Martin <>,
        Mark Brown <>,
        Eric Biggers <>,
        Will Deacon <>,
        Catalin Marinas <>,
        Thomas Gleixner <>,
        Peter Zijlstra <>,
        Sebastian Andrzej Siewior <>,
        Ingo Molnar <>
Subject: Re: [RFC PATCH 0/5] running kernel mode SIMD with softirqs disabled

On Fri, Dec 18, 2020 at 06:01:01PM +0100, Ard Biesheuvel wrote:
> Questions:
> - what did I miss or break horribly?
> - does any of this matter for RT? AIUI, RT runs softirqs from a dedicated
>   kthread, so I don't think it cares.
> - what would be a reasonable upper bound to keep softirqs disabled? I suppose
>   100s of cycles or less is overkill, but I'm not sure how to derive a better
>   answer.
> - could we do the same on x86, now that kernel_fpu_begin/end is no longer
>   expensive?

If this approach works not only would it allow us to support the
synchronous users better, it would also allow us to remove loads
of cruft in the Crypto API that exist solely to support these SIMD
code paths.

So I eagerly await the assessment of the scheduler/RT folks on this

Email: Herbert Xu <>
Home Page:
PGP Key:

Powered by blists - more mailing lists