On Fri, Jun 29, 2018 at 05:01:40PM -0700, Eric Biggers wrote: > From: Eric Biggers <ebigg...@google.com> > > I found that not only was sha256_mb sometimes computing the wrong digest > (fixed by a separately sent patch), but under normal workloads it's > hundreds of times slower than sha256-avx2, due to the flush delay. The > same applies to sha1_mb and sha512_mb. Yet, currently these can be the > highest priority implementations and therefore used by default. > Therefore, this series decreases their priority so that users have to > more explicitly opt-in to using them. > > Note that I don't believe the status quo of just having them behind > kernel config options is sufficient, since people often aren't familiar > with all the crypto options and error on the side of enabling too many. > And it's especially unexpected that enabling an "optimized" > implementation would actually make things 1000 times slower. > > Eric Biggers (4): > crypto: sha1_generic - add cra_priority > crypto: sha256_generic - add cra_priority > crypto: sha512_generic - add cra_priority > crypto: x86/sha-mb - decrease priority of multibuffer algorithms > > arch/x86/crypto/sha1-mb/sha1_mb.c | 9 ++++++++- > arch/x86/crypto/sha256-mb/sha256_mb.c | 9 ++++++++- > arch/x86/crypto/sha512-mb/sha512_mb.c | 9 ++++++++- > crypto/sha1_generic.c | 1 + > crypto/sha256_generic.c | 2 ++ > crypto/sha512_generic.c | 2 ++ > 6 files changed, 29 insertions(+), 3 deletions(-)
All applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
