On Wed, Oct 06, 2021 at 09:28:20AM -0400, Mike Snitzer wrote: > On Wed, Sep 29 2021 at 12:35P -0400, > Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > > > blk_keyslot_manager is misnamed because it doesn't necessarily manage > > keyslots. It actually does several different things: > > > > - Contains the crypto capabilities of the device. > > > > - Provides functions to control the inline encryption hardware. > > Originally these were just for programming/evicting keyslots; > > however, new functionality (hardware-wrapped keys) will require new > > functions here which are unrelated to keyslots. Moreover, > > device-mapper devices already (ab)use "keyslot_evict" to pass key > > eviction requests to their underlying devices even though > > device-mapper devices don't have any keyslots themselves (so it > > really should be "evict_key", not "keyslot_evict"). > > > > - Sometimes (but not always!) it manages keyslots. Originally it > > always did, but device-mapper devices don't have keyslots > > themselves, so they use a "passthrough keyslot manager" which > > doesn't actually manage keyslots. This hack works, but the > > terminology is unnatural. Also, some hardware doesn't have keyslots > > and thus also uses a "passthrough keyslot manager" (support for such > > hardware is yet to be upstreamed, but it will happen eventually). > > > > Let's stop having keyslot managers which don't actually manage keyslots. > > Instead, rename blk_keyslot_manager to blk_crypto_profile. > > > > This is a fairly big change, since for consistency it also has to update > > keyslot manager-related function names, variable names, and comments -- > > not just the actual struct name. However it's still a fairly > > straightforward change, as it doesn't change any actual functionality. > > > > Acked-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx> # For MMC > > Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx> > > Unfortunate how fiddley this change forced you to get but it looks > like you've done a very solid job of cleaning it all up to be > consistent. > > Reviewed-by: Mike Snitzer <snitzer@xxxxxxxxxx> > Thanks for the reviews! Yes, we should have done it this way originally which would have saved some pain, but better late than never. Jens, anything else you're waiting for before applying this series? Note that I'm not sure that Satya will leave any feedback, given that he's no longer working for Google, so any kernel work he does is in his free time. - Eric
