| Message ID | 20210913013135.102404-1-ebiggers@kernel.org |
|---|---|
| Headers | show |
| Series | blk-crypto cleanups | expand |
On Mon, 13 Sept 2021 at 03:35, Eric Biggers <ebiggers@kernel.org> wrote: > > From: Eric Biggers <ebiggers@google.com> > > In preparation for renaming struct blk_keyslot_manager to struct > blk_crypto_profile, rename the keyslot-manager.h and keyslot-manager.c > source files. Renaming these files separately before making a lot of > changes to their contents makes it easier for git to understand that > they were renamed. > > Signed-off-by: Eric Biggers <ebiggers@google.com> > --- > block/Makefile | 2 +- > block/blk-crypto-fallback.c | 2 +- > block/{keyslot-manager.c => blk-crypto-profile.c} | 2 +- > block/blk-crypto.c | 2 +- > drivers/md/dm-core.h | 2 +- > drivers/md/dm.c | 2 +- > drivers/mmc/host/cqhci-crypto.c | 2 +- > drivers/scsi/ufs/ufshcd.h | 2 +- > include/linux/{keyslot-manager.h => blk-crypto-profile.h} | 0 > include/linux/mmc/host.h | 2 +- > 10 files changed, 9 insertions(+), 9 deletions(-) > rename block/{keyslot-manager.c => blk-crypto-profile.c} (99%) > rename include/linux/{keyslot-manager.h => blk-crypto-profile.h} (100%) Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC [...] Kind regards Uffe
On Mon, 13 Sept 2021 at 03:35, Eric Biggers <ebiggers@kernel.org> wrote: > > From: Eric Biggers <ebiggers@google.com> > > 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. > > Signed-off-by: Eric Biggers <ebiggers@google.com> > --- > block/blk-crypto-fallback.c | 60 ++-- > block/blk-crypto-profile.c | 518 ++++++++++++++--------------- > block/blk-crypto.c | 25 +- > block/blk-integrity.c | 2 +- > drivers/md/dm-core.h | 2 +- > drivers/md/dm-table.c | 168 +++++----- > drivers/md/dm.c | 8 +- > drivers/mmc/core/crypto.c | 11 +- > drivers/mmc/host/cqhci-crypto.c | 31 +- > drivers/scsi/ufs/ufshcd-crypto.c | 32 +- > drivers/scsi/ufs/ufshcd-crypto.h | 9 +- > drivers/scsi/ufs/ufshcd.c | 2 +- > drivers/scsi/ufs/ufshcd.h | 4 +- > include/linux/blk-crypto-profile.h | 164 +++++---- > include/linux/blkdev.h | 18 +- > include/linux/device-mapper.h | 4 +- > include/linux/mmc/host.h | 2 +- > 17 files changed, 548 insertions(+), 512 deletions(-) > Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC [...] Kind regards Uffe
On Sun, Sep 12, 2021 at 06:31:34PM -0700, Eric Biggers wrote: > diff --git a/block/blk-integrity.c b/block/blk-integrity.c > index 69a12177dfb62..db656d12050f7 100644 > --- a/block/blk-integrity.c > +++ b/block/blk-integrity.c > @@ -411,7 +411,7 @@ void blk_integrity_register(struct gendisk *disk, struct blk_integrity *template > #ifdef CONFIG_BLK_INLINE_ENCRYPTION > if (disk->queue->ksm) { > pr_warn("blk-integrity: Integrity and hardware inline encryption are not supported together. Disabling hardware inline encryption.\n"); > - blk_ksm_unregister(disk->queue); > + blk_crypto_unregister(disk->queue); > } > #endif > } Note, there is a build error here when CONFIG_BLK_DEV_INTEGRITY=y, so I'll have to send a new version even if there are no other comments. - Eric
On Sun, Sep 12, 2021 at 06:31:31PM -0700, Eric Biggers wrote: > From: Eric Biggers <ebiggers@google.com> > > For clarity, avoid using just the "blk_crypto_" prefix for functions and > structs that are specific to blk-crypto-fallback. Instead, use > "blk_crypto_fallback_". Some places already did this, but others > didn't. > > This is also a prerequisite for using "struct blk_crypto_keyslot" to > mean a generic blk-crypto keyslot (which is what it sounds like). > Rename the fallback one to "struct blk_crypto_fallback_keyslot". > > Signed-off-by: Eric Biggers <ebiggers@google.com> These names are pretty long, but given that there aren't all the many of them: Reviewed-by: Christoph Hellwig <hch@lst.de>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
It would be nice to keep the blk-crypto* includes together, though.
On Wed, Sep 15, 2021 at 08:45:00AM +0100, Christoph Hellwig wrote: > Looks good: > > Reviewed-by: Christoph Hellwig <hch@lst.de> > > It would be nice to keep the blk-crypto* includes together, though. I don't see any case in which they aren't together. Unless you're talking about blk-crypto-internal.h, which is a directory-local header so it doesn't get grouped with the <linux/*.h> headers. - Eric
On Wed, Sep 15, 2021 at 10:40:53AM -0700, Eric Biggers wrote: > > It would be nice to keep the blk-crypto* includes together, though. > > I don't see any case in which they aren't together. Unless you're talking about > blk-crypto-internal.h, which is a directory-local header so it doesn't get > grouped with the <linux/*.h> headers. You're right. I skimmed over the patch too quickly.