On Mon, Nov 20, 2017 at 10:42 PM, Eric Biggers wrote:
> +Cc keyri...@vger.kernel.org (for asymmetric_keys)
>
> First of all, thanks for working on this! A lot of this code really needs to
> be
> better tested.
>
> On Mon, Nov 20, 2017 at 03:10:55PM +0100, Alexander Potapenko wrote:
>> Hi all,
>>
Most crypto drivers involving kernel mode NEON take care to put the code
that actually touches the NEON register file in a separate compilation
unit, to prevent the compiler from reordering code that preserves or
restores the NEON context with code that may corrupt it. This is
necessary because we
Checked for transcription errors, calling convention, and removal of
temporary locals. LGTM.
Reviewed-By: Nick Desaulniers
On Tue, Nov 21, 2017 at 5:40 AM, Ard Biesheuvel
wrote:
> Most crypto drivers involving kernel mode NEON take care to put the code
> that actually touches the NEON register
On Tue, Nov 21, 2017 at 09:00:26AM +0100, Dmitry Vyukov wrote:
> >
> > Note that separate from asymmetric_keys (which you can think of as being
> > in-between the keyrings subsystem and the crypto subsystem) there is also
> > the
> > userspace interface to cryptographic algorithms, AF_ALG. It mig
Make the cryptd queue length configurable. We recently had customer where this
needed to be tuned to accommodate the aesni_intel module and prevent packet
drop.
Signed-off-by: Jon Maxwell
---
crypto/cryptd.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/crypto/cryp
