On Fri, Feb 21, 2020 at 09:35:39AM -0800, Christoph Hellwig wrote: > High-level question: Does the whole keyslot manager concept even make > sense for the fallback? With the work-queue we have item that exectutes > at a time per cpu. So just allocatea per-cpu crypto_skcipher for > each encryption mode and there should never be a slot limitation. Or > do I miss something? It does make sense because if blk-crypto-fallback didn't use a keyslot manager, it would have to call crypto_skcipher_setkey() on the I/O path for every bio to ensure that the CPU's crypto_skcipher has the correct key. That's undesirable, because setting a new key can be expensive with some encryption algorithms, and also it can require a memory allocation which can fail. For example, with the Adiantum algorithm, setting a key requires encrypting ~1100 bytes of data in order to generate subkeys. It's better to set a key once and use it many times. Making blk-crypto-fallback use the keyslot manager also allows the keyslot manager to be tested by routine filesystem regression testing, e.g. 'gce-xfstests -c ext4/encrypt -g auto -m inlinecrypt'. - Eric
