diff options
author | Eric Biggers <ebiggers@google.com> | 2020-07-09 23:20:39 -0700 |
---|---|---|
committer | Herbert Xu <herbert@gondor.apana.org.au> | 2020-07-16 21:49:08 +1000 |
commit | 2eb27c11937ee9984c04b75d213a737291c5f58c (patch) | |
tree | 1665e908ce8a0e7e153fe9f77b2ddca77867c7dc /crypto/ccm.c | |
parent | 7bcb2c99f8ed032cfb3f5596b4dccac6b1f501df (diff) | |
download | linux-2eb27c11937ee9984c04b75d213a737291c5f58c.tar.gz linux-2eb27c11937ee9984c04b75d213a737291c5f58c.tar.bz2 linux-2eb27c11937ee9984c04b75d213a737291c5f58c.zip |
crypto: algapi - add NEED_FALLBACK to INHERITED_FLAGS
CRYPTO_ALG_NEED_FALLBACK is handled inconsistently. When it's requested
to be clear, some templates propagate that request to child algorithms,
while others don't.
It's apparently desired for NEED_FALLBACK to be propagated, to avoid
deadlocks where a module tries to load itself while it's being
initialized, and to avoid unnecessarily complex fallback chains where we
have e.g. cbc-aes-$driver falling back to cbc(aes-$driver) where
aes-$driver itself falls back to aes-generic, instead of cbc-aes-$driver
simply falling back to cbc(aes-generic). There have been a number of
fixes to this effect:
commit 89027579bc6c ("crypto: xts - Propagate NEED_FALLBACK bit")
commit d2c2a85cfe82 ("crypto: ctr - Propagate NEED_FALLBACK bit")
commit e6c2e65c70a6 ("crypto: cbc - Propagate NEED_FALLBACK bit")
But it seems that other templates can have the same problems too.
To avoid this whack-a-mole, just add NEED_FALLBACK to INHERITED_FLAGS so
that it's always inherited.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'crypto/ccm.c')
0 files changed, 0 insertions, 0 deletions