Re: Deadlock when using crypto API for block devices

2018-08-23 Thread Herbert Xu
On Thu, Aug 23, 2018 at 04:39:23PM -0400, Mikulas Patocka wrote: > > 1. don't set CRYPTO_TFM_REQ_MAY_SLEEP in dm-crypt > = > If we don't set it, dm-crypt will use GFP_ATOMIC and GFP_ATOMIC may fail. > The function init_crypt in xts.c handles the fail

Re: Backport e666d4e9ceec crypto: vmx - Use skcipher for ctr fallback

2018-08-23 Thread Herbert Xu
On Thu, Aug 23, 2018 at 05:31:01PM +0200, Petr Vorel wrote: > Hi, > > I wonder, it it makes sense to backport commit > e666d4e9ceec crypto: vmx - Use skcipher for ctr fallback > to v 4.14 stable kernel. > I'm using it in 4.12+. > > These commits (somehow similar) has been backported to 4.10.2: >

Re: [PATCH v2] crypto: arm64/aes-modes - get rid of literal load of addend vector

2018-08-23 Thread Ard Biesheuvel
On 23 August 2018 at 21:04, Nick Desaulniers wrote: > On Thu, Aug 23, 2018 at 9:48 AM Ard Biesheuvel > wrote: >> >> Replace the literal load of the addend vector with a sequence that >> performs each add individually. This sequence is only 2 instructions >> longer than the original, and 2% faster

Deadlock when using crypto API for block devices

2018-08-23 Thread Mikulas Patocka
Hi There's a deadlock reported here: https://bugzilla.kernel.org/show_bug.cgi?id=200835 * dm-crypt calls crypt_convert in xts mode * init_crypt from xts.c calls kmalloc(GFP_KERNEL) * kmalloc(GFP_KERNEL) recurses into the XFS filesystem, the filesystem tries to submit some bios and wait

Re: [PATCH v2] crypto: vmx - Fix sleep-in-atomic bugs

2018-08-23 Thread Paulo Flabiano Smorigo
On 2018-08-22 21:04, Marcelo Henrique Cerri wrote: That looks good to me. Maybe Paulo can help testing it. -- Regards, Marcelo On Wed, Aug 22, 2018 at 08:26:31AM +0200, Ondrej Mosnacek wrote: This patch fixes sleep-in-atomic bugs in AES-CBC and AES-XTS VMX implementations. The problem is that

Re: [PATCH v2] crypto: arm64/aes-modes - get rid of literal load of addend vector

2018-08-23 Thread Nick Desaulniers
On Thu, Aug 23, 2018 at 9:48 AM Ard Biesheuvel wrote: > > Replace the literal load of the addend vector with a sequence that > performs each add individually. This sequence is only 2 instructions > longer than the original, and 2% faster on Cortex-A53. > > This is an improvement by itself, but als

[PATCH v2] crypto: arm64/aes-modes - get rid of literal load of addend vector

2018-08-23 Thread Ard Biesheuvel
Replace the literal load of the addend vector with a sequence that performs each add individually. This sequence is only 2 instructions longer than the original, and 2% faster on Cortex-A53. This is an improvement by itself, but also works around a Clang issue, whose integrated assembler does not

Backport e666d4e9ceec crypto: vmx - Use skcipher for ctr fallback

2018-08-23 Thread Petr Vorel
Hi, I wonder, it it makes sense to backport commit e666d4e9ceec crypto: vmx - Use skcipher for ctr fallback to v 4.14 stable kernel. I'm using it in 4.12+. These commits (somehow similar) has been backported to 4.10.2: 5839f555fa57 crypto: vmx - Use skcipher for xts fallback c96d0a1c47ab crypto:

[PATCH v2] crypto: arm/ghash-ce - implement support for 4-way aggregation

2018-08-23 Thread Ard Biesheuvel
Speed up the GHASH algorithm based on 64-bit polynomial multiplication by adding support for 4-way aggregation. This improves throughput by ~85% on Cortex-A53, from 1.7 cycles per byte to 0.9 cycles per byte. When combined with AES into GCM, throughput improves by ~25%, from 3.8 cycles per byte to