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(-) -- 2.18.0.399.gad0ab374a1-goog
