* [dm-devel] pass a struct block_device to the blk-crypto interfaces v2 @ 2022-11-07 14:42 ` Christoph Hellwig 0 siblings, 0 replies; 18+ messages in thread From: Christoph Hellwig @ 2022-11-07 14:42 UTC (permalink / raw) To: Jens Axboe Cc: linux-block, Theodore Y. Ts'o, Mike Snitzer, linux-fscrypt, Eric Biggers, dm-devel, Jaegeuk Kim Hi all, this series switches the blk-crypto interfaces to take block_device arguments instead of request_queues, and with that finishes off the project to hide struct request_queue from file systems. Changes since v1: - keep using request_queue in the Documentation for driver interfaces - rename to blk_crypto_cfg_supported to blk_crypto_config_supported_natively and move it to blk-crypto.[ch] - mark __blk_crypto_cfg_supported private Diffstat: Documentation/block/inline-encryption.rst | 12 +++++----- block/blk-crypto-internal.h | 3 ++ block/blk-crypto.c | 33 ++++++++++++++++++------------ drivers/md/dm-table.c | 2 - fs/crypto/inline_crypt.c | 14 ++++-------- include/linux/blk-crypto-profile.h | 3 -- include/linux/blk-crypto.h | 10 +++++---- 7 files changed, 41 insertions(+), 36 deletions(-) -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* pass a struct block_device to the blk-crypto interfaces v2 @ 2022-11-07 14:42 ` Christoph Hellwig 0 siblings, 0 replies; 18+ messages in thread From: Christoph Hellwig @ 2022-11-07 14:42 UTC (permalink / raw) To: Jens Axboe Cc: Mike Snitzer, Theodore Y. Ts'o, Jaegeuk Kim, Eric Biggers, dm-devel, linux-block, linux-fscrypt Hi all, this series switches the blk-crypto interfaces to take block_device arguments instead of request_queues, and with that finishes off the project to hide struct request_queue from file systems. Changes since v1: - keep using request_queue in the Documentation for driver interfaces - rename to blk_crypto_cfg_supported to blk_crypto_config_supported_natively and move it to blk-crypto.[ch] - mark __blk_crypto_cfg_supported private Diffstat: Documentation/block/inline-encryption.rst | 12 +++++----- block/blk-crypto-internal.h | 3 ++ block/blk-crypto.c | 33 ++++++++++++++++++------------ drivers/md/dm-table.c | 2 - fs/crypto/inline_crypt.c | 14 ++++-------- include/linux/blk-crypto-profile.h | 3 -- include/linux/blk-crypto.h | 10 +++++---- 7 files changed, 41 insertions(+), 36 deletions(-) ^ permalink raw reply [flat|nested] 18+ messages in thread
* [dm-devel] [PATCH 1/3] blk-crypto: don't use struct request_queue for public interfaces 2022-11-07 14:42 ` Christoph Hellwig @ 2022-11-07 14:42 ` Christoph Hellwig -1 siblings, 0 replies; 18+ messages in thread From: Christoph Hellwig @ 2022-11-07 14:42 UTC (permalink / raw) To: Jens Axboe Cc: linux-block, Theodore Y. Ts'o, Mike Snitzer, linux-fscrypt, Eric Biggers, dm-devel, Jaegeuk Kim Switch all public blk-crypto interfaces to use struct block_device arguments to specify the device they operate on instead of th request_queue, which is a block layer implementation detail. Signed-off-by: Christoph Hellwig <hch@lst.de> --- Documentation/block/inline-encryption.rst | 12 ++++++------ block/blk-crypto.c | 20 ++++++++++++-------- drivers/md/dm-table.c | 2 +- fs/crypto/inline_crypt.c | 8 +++----- include/linux/blk-crypto.h | 8 ++++---- 5 files changed, 26 insertions(+), 24 deletions(-) diff --git a/Documentation/block/inline-encryption.rst b/Documentation/block/inline-encryption.rst index 4d151fbe20583..f9bf18ea65093 100644 --- a/Documentation/block/inline-encryption.rst +++ b/Documentation/block/inline-encryption.rst @@ -142,7 +142,7 @@ Therefore, we also introduce *blk-crypto-fallback*, which is an implementation of inline encryption using the kernel crypto API. blk-crypto-fallback is built into the block layer, so it works on any block device without any special setup. Essentially, when a bio with an encryption context is submitted to a -request_queue that doesn't support that encryption context, the block layer will +block_device that doesn't support that encryption context, the block layer will handle en/decryption of the bio using blk-crypto-fallback. For encryption, the data cannot be encrypted in-place, as callers usually rely @@ -187,7 +187,7 @@ API presented to users of the block layer ``blk_crypto_config_supported()`` allows users to check ahead of time whether inline encryption with particular crypto settings will work on a particular -request_queue -- either via hardware or via blk-crypto-fallback. This function +block_device -- either via hardware or via blk-crypto-fallback. This function takes in a ``struct blk_crypto_config`` which is like blk_crypto_key, but omits the actual bytes of the key and instead just contains the algorithm, data unit size, etc. This function can be useful if blk-crypto-fallback is disabled. @@ -195,7 +195,7 @@ size, etc. This function can be useful if blk-crypto-fallback is disabled. ``blk_crypto_init_key()`` allows users to initialize a blk_crypto_key. Users must call ``blk_crypto_start_using_key()`` before actually starting to use -a blk_crypto_key on a request_queue (even if ``blk_crypto_config_supported()`` +a blk_crypto_key on a block_device (even if ``blk_crypto_config_supported()`` was called earlier). This is needed to initialize blk-crypto-fallback if it will be needed. This must not be called from the data path, as this may have to allocate resources, which may deadlock in that case. @@ -207,7 +207,7 @@ for en/decryption. Users don't need to worry about freeing the bio_crypt_ctx later, as that happens automatically when the bio is freed or reset. Finally, when done using inline encryption with a blk_crypto_key on a -request_queue, users must call ``blk_crypto_evict_key()``. This ensures that +block_device, users must call ``blk_crypto_evict_key()``. This ensures that the key is evicted from all keyslots it may be programmed into and unlinked from any kernel data structures it may be linked into. @@ -221,9 +221,9 @@ as follows: 5. ``blk_crypto_evict_key()`` (after all I/O has completed) 6. Zeroize the blk_crypto_key (this has no dedicated function) -If a blk_crypto_key is being used on multiple request_queues, then +If a blk_crypto_key is being used on multiple block_devices, then ``blk_crypto_config_supported()`` (if used), ``blk_crypto_start_using_key()``, -and ``blk_crypto_evict_key()`` must be called on each request_queue. +and ``blk_crypto_evict_key()`` must be called on each block_device. API presented to device drivers =============================== diff --git a/block/blk-crypto.c b/block/blk-crypto.c index a496aaef85ba4..0e0c2fc56c428 100644 --- a/block/blk-crypto.c +++ b/block/blk-crypto.c @@ -357,17 +357,18 @@ int blk_crypto_init_key(struct blk_crypto_key *blk_key, const u8 *raw_key, * request queue it's submitted to supports inline crypto, or the * blk-crypto-fallback is enabled and supports the cfg). */ -bool blk_crypto_config_supported(struct request_queue *q, +bool blk_crypto_config_supported(struct block_device *bdev, const struct blk_crypto_config *cfg) { return IS_ENABLED(CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK) || - __blk_crypto_cfg_supported(q->crypto_profile, cfg); + __blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, + cfg); } /** * blk_crypto_start_using_key() - Start using a blk_crypto_key on a device + * @bdev: block device to operate on * @key: A key to use on the device - * @q: the request queue for the device * * Upper layers must call this function to ensure that either the hardware * supports the key's crypto settings, or the crypto API fallback has transforms @@ -379,10 +380,11 @@ bool blk_crypto_config_supported(struct request_queue *q, * blk-crypto-fallback is either disabled or the needed algorithm * is disabled in the crypto API; or another -errno code. */ -int blk_crypto_start_using_key(const struct blk_crypto_key *key, - struct request_queue *q) +int blk_crypto_start_using_key(struct block_device *bdev, + const struct blk_crypto_key *key) { - if (__blk_crypto_cfg_supported(q->crypto_profile, &key->crypto_cfg)) + if (__blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, + &key->crypto_cfg)) return 0; return blk_crypto_fallback_start_using_mode(key->crypto_cfg.crypto_mode); } @@ -390,7 +392,7 @@ int blk_crypto_start_using_key(const struct blk_crypto_key *key, /** * blk_crypto_evict_key() - Evict a key from any inline encryption hardware * it may have been programmed into - * @q: The request queue who's associated inline encryption hardware this key + * @bdev: The block_device who's associated inline encryption hardware this key * might have been programmed into * @key: The key to evict * @@ -400,9 +402,11 @@ int blk_crypto_start_using_key(const struct blk_crypto_key *key, * * Return: 0 on success or if the key wasn't in any keyslot; -errno on error. */ -int blk_crypto_evict_key(struct request_queue *q, +int blk_crypto_evict_key(struct block_device *bdev, const struct blk_crypto_key *key) { + struct request_queue *q = bdev_get_queue(bdev); + if (__blk_crypto_cfg_supported(q->crypto_profile, &key->crypto_cfg)) return __blk_crypto_evict_key(q->crypto_profile, key); diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c index 078da18bb86d8..8541d5688f3a6 100644 --- a/drivers/md/dm-table.c +++ b/drivers/md/dm-table.c @@ -1215,7 +1215,7 @@ static int dm_keyslot_evict_callback(struct dm_target *ti, struct dm_dev *dev, struct dm_keyslot_evict_args *args = data; int err; - err = blk_crypto_evict_key(bdev_get_queue(dev->bdev), args->key); + err = blk_crypto_evict_key(dev->bdev, args->key); if (!args->err) args->err = err; /* Always try to evict the key from all devices. */ diff --git a/fs/crypto/inline_crypt.c b/fs/crypto/inline_crypt.c index cea8b14007e6a..55c4d8c23d30d 100644 --- a/fs/crypto/inline_crypt.c +++ b/fs/crypto/inline_crypt.c @@ -139,8 +139,7 @@ int fscrypt_select_encryption_impl(struct fscrypt_info *ci) return PTR_ERR(devs); for (i = 0; i < num_devs; i++) { - if (!blk_crypto_config_supported(bdev_get_queue(devs[i]), - &crypto_cfg)) + if (!blk_crypto_config_supported(devs[i], &crypto_cfg)) goto out_free_devs; } @@ -184,8 +183,7 @@ int fscrypt_prepare_inline_crypt_key(struct fscrypt_prepared_key *prep_key, goto fail; } for (i = 0; i < num_devs; i++) { - err = blk_crypto_start_using_key(blk_key, - bdev_get_queue(devs[i])); + err = blk_crypto_start_using_key(devs[i], blk_key); if (err) break; } @@ -224,7 +222,7 @@ void fscrypt_destroy_inline_crypt_key(struct super_block *sb, devs = fscrypt_get_devices(sb, &num_devs); if (!IS_ERR(devs)) { for (i = 0; i < num_devs; i++) - blk_crypto_evict_key(bdev_get_queue(devs[i]), blk_key); + blk_crypto_evict_key(devs[i], blk_key); kfree(devs); } kfree_sensitive(blk_key); diff --git a/include/linux/blk-crypto.h b/include/linux/blk-crypto.h index 69b24fe92cbf1..b314e2febcaf5 100644 --- a/include/linux/blk-crypto.h +++ b/include/linux/blk-crypto.h @@ -94,13 +94,13 @@ int blk_crypto_init_key(struct blk_crypto_key *blk_key, const u8 *raw_key, unsigned int dun_bytes, unsigned int data_unit_size); -int blk_crypto_start_using_key(const struct blk_crypto_key *key, - struct request_queue *q); +int blk_crypto_start_using_key(struct block_device *bdev, + const struct blk_crypto_key *key); -int blk_crypto_evict_key(struct request_queue *q, +int blk_crypto_evict_key(struct block_device *bdev, const struct blk_crypto_key *key); -bool blk_crypto_config_supported(struct request_queue *q, +bool blk_crypto_config_supported(struct block_device *bdev, const struct blk_crypto_config *cfg); #else /* CONFIG_BLK_INLINE_ENCRYPTION */ -- 2.30.2 -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH 1/3] blk-crypto: don't use struct request_queue for public interfaces @ 2022-11-07 14:42 ` Christoph Hellwig 0 siblings, 0 replies; 18+ messages in thread From: Christoph Hellwig @ 2022-11-07 14:42 UTC (permalink / raw) To: Jens Axboe Cc: Mike Snitzer, Theodore Y. Ts'o, Jaegeuk Kim, Eric Biggers, dm-devel, linux-block, linux-fscrypt Switch all public blk-crypto interfaces to use struct block_device arguments to specify the device they operate on instead of th request_queue, which is a block layer implementation detail. Signed-off-by: Christoph Hellwig <hch@lst.de> --- Documentation/block/inline-encryption.rst | 12 ++++++------ block/blk-crypto.c | 20 ++++++++++++-------- drivers/md/dm-table.c | 2 +- fs/crypto/inline_crypt.c | 8 +++----- include/linux/blk-crypto.h | 8 ++++---- 5 files changed, 26 insertions(+), 24 deletions(-) diff --git a/Documentation/block/inline-encryption.rst b/Documentation/block/inline-encryption.rst index 4d151fbe20583..f9bf18ea65093 100644 --- a/Documentation/block/inline-encryption.rst +++ b/Documentation/block/inline-encryption.rst @@ -142,7 +142,7 @@ Therefore, we also introduce *blk-crypto-fallback*, which is an implementation of inline encryption using the kernel crypto API. blk-crypto-fallback is built into the block layer, so it works on any block device without any special setup. Essentially, when a bio with an encryption context is submitted to a -request_queue that doesn't support that encryption context, the block layer will +block_device that doesn't support that encryption context, the block layer will handle en/decryption of the bio using blk-crypto-fallback. For encryption, the data cannot be encrypted in-place, as callers usually rely @@ -187,7 +187,7 @@ API presented to users of the block layer ``blk_crypto_config_supported()`` allows users to check ahead of time whether inline encryption with particular crypto settings will work on a particular -request_queue -- either via hardware or via blk-crypto-fallback. This function +block_device -- either via hardware or via blk-crypto-fallback. This function takes in a ``struct blk_crypto_config`` which is like blk_crypto_key, but omits the actual bytes of the key and instead just contains the algorithm, data unit size, etc. This function can be useful if blk-crypto-fallback is disabled. @@ -195,7 +195,7 @@ size, etc. This function can be useful if blk-crypto-fallback is disabled. ``blk_crypto_init_key()`` allows users to initialize a blk_crypto_key. Users must call ``blk_crypto_start_using_key()`` before actually starting to use -a blk_crypto_key on a request_queue (even if ``blk_crypto_config_supported()`` +a blk_crypto_key on a block_device (even if ``blk_crypto_config_supported()`` was called earlier). This is needed to initialize blk-crypto-fallback if it will be needed. This must not be called from the data path, as this may have to allocate resources, which may deadlock in that case. @@ -207,7 +207,7 @@ for en/decryption. Users don't need to worry about freeing the bio_crypt_ctx later, as that happens automatically when the bio is freed or reset. Finally, when done using inline encryption with a blk_crypto_key on a -request_queue, users must call ``blk_crypto_evict_key()``. This ensures that +block_device, users must call ``blk_crypto_evict_key()``. This ensures that the key is evicted from all keyslots it may be programmed into and unlinked from any kernel data structures it may be linked into. @@ -221,9 +221,9 @@ as follows: 5. ``blk_crypto_evict_key()`` (after all I/O has completed) 6. Zeroize the blk_crypto_key (this has no dedicated function) -If a blk_crypto_key is being used on multiple request_queues, then +If a blk_crypto_key is being used on multiple block_devices, then ``blk_crypto_config_supported()`` (if used), ``blk_crypto_start_using_key()``, -and ``blk_crypto_evict_key()`` must be called on each request_queue. +and ``blk_crypto_evict_key()`` must be called on each block_device. API presented to device drivers =============================== diff --git a/block/blk-crypto.c b/block/blk-crypto.c index a496aaef85ba4..0e0c2fc56c428 100644 --- a/block/blk-crypto.c +++ b/block/blk-crypto.c @@ -357,17 +357,18 @@ int blk_crypto_init_key(struct blk_crypto_key *blk_key, const u8 *raw_key, * request queue it's submitted to supports inline crypto, or the * blk-crypto-fallback is enabled and supports the cfg). */ -bool blk_crypto_config_supported(struct request_queue *q, +bool blk_crypto_config_supported(struct block_device *bdev, const struct blk_crypto_config *cfg) { return IS_ENABLED(CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK) || - __blk_crypto_cfg_supported(q->crypto_profile, cfg); + __blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, + cfg); } /** * blk_crypto_start_using_key() - Start using a blk_crypto_key on a device + * @bdev: block device to operate on * @key: A key to use on the device - * @q: the request queue for the device * * Upper layers must call this function to ensure that either the hardware * supports the key's crypto settings, or the crypto API fallback has transforms @@ -379,10 +380,11 @@ bool blk_crypto_config_supported(struct request_queue *q, * blk-crypto-fallback is either disabled or the needed algorithm * is disabled in the crypto API; or another -errno code. */ -int blk_crypto_start_using_key(const struct blk_crypto_key *key, - struct request_queue *q) +int blk_crypto_start_using_key(struct block_device *bdev, + const struct blk_crypto_key *key) { - if (__blk_crypto_cfg_supported(q->crypto_profile, &key->crypto_cfg)) + if (__blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, + &key->crypto_cfg)) return 0; return blk_crypto_fallback_start_using_mode(key->crypto_cfg.crypto_mode); } @@ -390,7 +392,7 @@ int blk_crypto_start_using_key(const struct blk_crypto_key *key, /** * blk_crypto_evict_key() - Evict a key from any inline encryption hardware * it may have been programmed into - * @q: The request queue who's associated inline encryption hardware this key + * @bdev: The block_device who's associated inline encryption hardware this key * might have been programmed into * @key: The key to evict * @@ -400,9 +402,11 @@ int blk_crypto_start_using_key(const struct blk_crypto_key *key, * * Return: 0 on success or if the key wasn't in any keyslot; -errno on error. */ -int blk_crypto_evict_key(struct request_queue *q, +int blk_crypto_evict_key(struct block_device *bdev, const struct blk_crypto_key *key) { + struct request_queue *q = bdev_get_queue(bdev); + if (__blk_crypto_cfg_supported(q->crypto_profile, &key->crypto_cfg)) return __blk_crypto_evict_key(q->crypto_profile, key); diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c index 078da18bb86d8..8541d5688f3a6 100644 --- a/drivers/md/dm-table.c +++ b/drivers/md/dm-table.c @@ -1215,7 +1215,7 @@ static int dm_keyslot_evict_callback(struct dm_target *ti, struct dm_dev *dev, struct dm_keyslot_evict_args *args = data; int err; - err = blk_crypto_evict_key(bdev_get_queue(dev->bdev), args->key); + err = blk_crypto_evict_key(dev->bdev, args->key); if (!args->err) args->err = err; /* Always try to evict the key from all devices. */ diff --git a/fs/crypto/inline_crypt.c b/fs/crypto/inline_crypt.c index cea8b14007e6a..55c4d8c23d30d 100644 --- a/fs/crypto/inline_crypt.c +++ b/fs/crypto/inline_crypt.c @@ -139,8 +139,7 @@ int fscrypt_select_encryption_impl(struct fscrypt_info *ci) return PTR_ERR(devs); for (i = 0; i < num_devs; i++) { - if (!blk_crypto_config_supported(bdev_get_queue(devs[i]), - &crypto_cfg)) + if (!blk_crypto_config_supported(devs[i], &crypto_cfg)) goto out_free_devs; } @@ -184,8 +183,7 @@ int fscrypt_prepare_inline_crypt_key(struct fscrypt_prepared_key *prep_key, goto fail; } for (i = 0; i < num_devs; i++) { - err = blk_crypto_start_using_key(blk_key, - bdev_get_queue(devs[i])); + err = blk_crypto_start_using_key(devs[i], blk_key); if (err) break; } @@ -224,7 +222,7 @@ void fscrypt_destroy_inline_crypt_key(struct super_block *sb, devs = fscrypt_get_devices(sb, &num_devs); if (!IS_ERR(devs)) { for (i = 0; i < num_devs; i++) - blk_crypto_evict_key(bdev_get_queue(devs[i]), blk_key); + blk_crypto_evict_key(devs[i], blk_key); kfree(devs); } kfree_sensitive(blk_key); diff --git a/include/linux/blk-crypto.h b/include/linux/blk-crypto.h index 69b24fe92cbf1..b314e2febcaf5 100644 --- a/include/linux/blk-crypto.h +++ b/include/linux/blk-crypto.h @@ -94,13 +94,13 @@ int blk_crypto_init_key(struct blk_crypto_key *blk_key, const u8 *raw_key, unsigned int dun_bytes, unsigned int data_unit_size); -int blk_crypto_start_using_key(const struct blk_crypto_key *key, - struct request_queue *q); +int blk_crypto_start_using_key(struct block_device *bdev, + const struct blk_crypto_key *key); -int blk_crypto_evict_key(struct request_queue *q, +int blk_crypto_evict_key(struct block_device *bdev, const struct blk_crypto_key *key); -bool blk_crypto_config_supported(struct request_queue *q, +bool blk_crypto_config_supported(struct block_device *bdev, const struct blk_crypto_config *cfg); #else /* CONFIG_BLK_INLINE_ENCRYPTION */ -- 2.30.2 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [dm-devel] [PATCH 1/3] blk-crypto: don't use struct request_queue for public interfaces 2022-11-07 14:42 ` Christoph Hellwig @ 2022-11-07 20:16 ` Eric Biggers -1 siblings, 0 replies; 18+ messages in thread From: Eric Biggers @ 2022-11-07 20:16 UTC (permalink / raw) To: Christoph Hellwig Cc: Jens Axboe, Theodore Y. Ts'o, Mike Snitzer, linux-fscrypt, linux-block, dm-devel, Jaegeuk Kim On Mon, Nov 07, 2022 at 03:42:27PM +0100, Christoph Hellwig wrote: > diff --git a/block/blk-crypto.c b/block/blk-crypto.c > index a496aaef85ba4..0e0c2fc56c428 100644 > --- a/block/blk-crypto.c > +++ b/block/blk-crypto.c > @@ -357,17 +357,18 @@ int blk_crypto_init_key(struct blk_crypto_key *blk_key, const u8 *raw_key, > * request queue it's submitted to supports inline crypto, or the > * blk-crypto-fallback is enabled and supports the cfg). > */ Replace "request queue" with block_device in the above comment? > -bool blk_crypto_config_supported(struct request_queue *q, > +bool blk_crypto_config_supported(struct block_device *bdev, > const struct blk_crypto_config *cfg) > { > return IS_ENABLED(CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK) || > - __blk_crypto_cfg_supported(q->crypto_profile, cfg); > + __blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, > + cfg); > } There's a whitespace error here: $ checkpatch 0001-blk-crypto-don-t-use-struct-request_queue-for-public.patch ERROR: code indent should use tabs where possible #87: FILE: block/blk-crypto.c:365: +^I ^I^I^I^I cfg);$ WARNING: please, no space before tabs #87: FILE: block/blk-crypto.c:365: +^I ^I^I^I^I cfg);$ > -int blk_crypto_evict_key(struct request_queue *q, > +int blk_crypto_evict_key(struct block_device *bdev, > const struct blk_crypto_key *key) > { > + struct request_queue *q = bdev_get_queue(bdev); > + > if (__blk_crypto_cfg_supported(q->crypto_profile, &key->crypto_cfg)) > return __blk_crypto_evict_key(q->crypto_profile, key); > > /* > * If the request_queue didn't support the key, then blk-crypto-fallback > * may have been used, so try to evict the key from blk-crypto-fallback. > */ > return blk_crypto_fallback_evict_key(key); Likewise, s/request_queue/block_device/ in the above comment. > diff --git a/include/linux/blk-crypto.h b/include/linux/blk-crypto.h > index 69b24fe92cbf1..b314e2febcaf5 100644 > --- a/include/linux/blk-crypto.h > +++ b/include/linux/blk-crypto.h [...] > > struct request; > struct request_queue; These forward declarations are no longer needed and can be removed. - Eric -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/3] blk-crypto: don't use struct request_queue for public interfaces @ 2022-11-07 20:16 ` Eric Biggers 0 siblings, 0 replies; 18+ messages in thread From: Eric Biggers @ 2022-11-07 20:16 UTC (permalink / raw) To: Christoph Hellwig Cc: Jens Axboe, Mike Snitzer, Theodore Y. Ts'o, Jaegeuk Kim, dm-devel, linux-block, linux-fscrypt On Mon, Nov 07, 2022 at 03:42:27PM +0100, Christoph Hellwig wrote: > diff --git a/block/blk-crypto.c b/block/blk-crypto.c > index a496aaef85ba4..0e0c2fc56c428 100644 > --- a/block/blk-crypto.c > +++ b/block/blk-crypto.c > @@ -357,17 +357,18 @@ int blk_crypto_init_key(struct blk_crypto_key *blk_key, const u8 *raw_key, > * request queue it's submitted to supports inline crypto, or the > * blk-crypto-fallback is enabled and supports the cfg). > */ Replace "request queue" with block_device in the above comment? > -bool blk_crypto_config_supported(struct request_queue *q, > +bool blk_crypto_config_supported(struct block_device *bdev, > const struct blk_crypto_config *cfg) > { > return IS_ENABLED(CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK) || > - __blk_crypto_cfg_supported(q->crypto_profile, cfg); > + __blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, > + cfg); > } There's a whitespace error here: $ checkpatch 0001-blk-crypto-don-t-use-struct-request_queue-for-public.patch ERROR: code indent should use tabs where possible #87: FILE: block/blk-crypto.c:365: +^I ^I^I^I^I cfg);$ WARNING: please, no space before tabs #87: FILE: block/blk-crypto.c:365: +^I ^I^I^I^I cfg);$ > -int blk_crypto_evict_key(struct request_queue *q, > +int blk_crypto_evict_key(struct block_device *bdev, > const struct blk_crypto_key *key) > { > + struct request_queue *q = bdev_get_queue(bdev); > + > if (__blk_crypto_cfg_supported(q->crypto_profile, &key->crypto_cfg)) > return __blk_crypto_evict_key(q->crypto_profile, key); > > /* > * If the request_queue didn't support the key, then blk-crypto-fallback > * may have been used, so try to evict the key from blk-crypto-fallback. > */ > return blk_crypto_fallback_evict_key(key); Likewise, s/request_queue/block_device/ in the above comment. > diff --git a/include/linux/blk-crypto.h b/include/linux/blk-crypto.h > index 69b24fe92cbf1..b314e2febcaf5 100644 > --- a/include/linux/blk-crypto.h > +++ b/include/linux/blk-crypto.h [...] > > struct request; > struct request_queue; These forward declarations are no longer needed and can be removed. - Eric ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [dm-devel] [PATCH 1/3] blk-crypto: don't use struct request_queue for public interfaces 2022-11-07 20:16 ` Eric Biggers @ 2022-11-09 13:14 ` Christoph Hellwig -1 siblings, 0 replies; 18+ messages in thread From: Christoph Hellwig @ 2022-11-09 13:14 UTC (permalink / raw) To: Eric Biggers Cc: Jens Axboe, Theodore Y. Ts'o, Mike Snitzer, linux-fscrypt, linux-block, dm-devel, Jaegeuk Kim, Christoph Hellwig On Mon, Nov 07, 2022 at 12:16:22PM -0800, Eric Biggers wrote: > On Mon, Nov 07, 2022 at 03:42:27PM +0100, Christoph Hellwig wrote: > > diff --git a/block/blk-crypto.c b/block/blk-crypto.c > > index a496aaef85ba4..0e0c2fc56c428 100644 > > --- a/block/blk-crypto.c > > +++ b/block/blk-crypto.c > > @@ -357,17 +357,18 @@ int blk_crypto_init_key(struct blk_crypto_key *blk_key, const u8 *raw_key, > > * request queue it's submitted to supports inline crypto, or the > > * blk-crypto-fallback is enabled and supports the cfg). > > */ > > Replace "request queue" with block_device in the above comment? Done. > > - __blk_crypto_cfg_supported(q->crypto_profile, cfg); > > + __blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, > > + cfg); > > } > > There's a whitespace error here: Fixed. > > /* > > * If the request_queue didn't support the key, then blk-crypto-fallback > > * may have been used, so try to evict the key from blk-crypto-fallback. > > */ > > return blk_crypto_fallback_evict_key(key); > > Likewise, s/request_queue/block_device/ in the above comment. Done. > > struct request; > > struct request_queue; > > These forward declarations are no longer needed and can be removed. Done. -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/3] blk-crypto: don't use struct request_queue for public interfaces @ 2022-11-09 13:14 ` Christoph Hellwig 0 siblings, 0 replies; 18+ messages in thread From: Christoph Hellwig @ 2022-11-09 13:14 UTC (permalink / raw) To: Eric Biggers Cc: Christoph Hellwig, Jens Axboe, Mike Snitzer, Theodore Y. Ts'o, Jaegeuk Kim, dm-devel, linux-block, linux-fscrypt On Mon, Nov 07, 2022 at 12:16:22PM -0800, Eric Biggers wrote: > On Mon, Nov 07, 2022 at 03:42:27PM +0100, Christoph Hellwig wrote: > > diff --git a/block/blk-crypto.c b/block/blk-crypto.c > > index a496aaef85ba4..0e0c2fc56c428 100644 > > --- a/block/blk-crypto.c > > +++ b/block/blk-crypto.c > > @@ -357,17 +357,18 @@ int blk_crypto_init_key(struct blk_crypto_key *blk_key, const u8 *raw_key, > > * request queue it's submitted to supports inline crypto, or the > > * blk-crypto-fallback is enabled and supports the cfg). > > */ > > Replace "request queue" with block_device in the above comment? Done. > > - __blk_crypto_cfg_supported(q->crypto_profile, cfg); > > + __blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, > > + cfg); > > } > > There's a whitespace error here: Fixed. > > /* > > * If the request_queue didn't support the key, then blk-crypto-fallback > > * may have been used, so try to evict the key from blk-crypto-fallback. > > */ > > return blk_crypto_fallback_evict_key(key); > > Likewise, s/request_queue/block_device/ in the above comment. Done. > > struct request; > > struct request_queue; > > These forward declarations are no longer needed and can be removed. Done. ^ permalink raw reply [flat|nested] 18+ messages in thread
* [dm-devel] [PATCH 2/3] blk-crypto: add a blk_crypto_config_supported_natively helper 2022-11-07 14:42 ` Christoph Hellwig @ 2022-11-07 14:42 ` Christoph Hellwig -1 siblings, 0 replies; 18+ messages in thread From: Christoph Hellwig @ 2022-11-07 14:42 UTC (permalink / raw) To: Jens Axboe Cc: linux-block, Theodore Y. Ts'o, Mike Snitzer, linux-fscrypt, Eric Biggers, dm-devel, Jaegeuk Kim Add a blk_crypto_cfg_supported helper that wraps __blk_crypto_cfg_supported to retreive the crypto_profile from the request queue. With this fscrypt can stop including blk-crypto-profile.h and rely on the public consumer interface in blk-crypto.h. Signed-off-by: Christoph Hellwig <hch@lst.de> --- block/blk-crypto.c | 21 ++++++++++++--------- fs/crypto/inline_crypt.c | 6 ++---- include/linux/blk-crypto.h | 2 ++ 3 files changed, 16 insertions(+), 13 deletions(-) diff --git a/block/blk-crypto.c b/block/blk-crypto.c index 0e0c2fc56c428..ceb5a4c8f0306 100644 --- a/block/blk-crypto.c +++ b/block/blk-crypto.c @@ -267,7 +267,6 @@ bool __blk_crypto_bio_prep(struct bio **bio_ptr) { struct bio *bio = *bio_ptr; const struct blk_crypto_key *bc_key = bio->bi_crypt_context->bc_key; - struct blk_crypto_profile *profile; /* Error if bio has no data. */ if (WARN_ON_ONCE(!bio_has_data(bio))) { @@ -284,10 +283,9 @@ bool __blk_crypto_bio_prep(struct bio **bio_ptr) * Success if device supports the encryption context, or if we succeeded * in falling back to the crypto API. */ - profile = bdev_get_queue(bio->bi_bdev)->crypto_profile; - if (__blk_crypto_cfg_supported(profile, &bc_key->crypto_cfg)) + if (blk_crypto_config_supported_natively(bio->bi_bdev, + &bc_key->crypto_cfg)) return true; - if (blk_crypto_fallback_bio_prep(bio_ptr)) return true; fail: @@ -352,6 +350,13 @@ int blk_crypto_init_key(struct blk_crypto_key *blk_key, const u8 *raw_key, return 0; } +bool blk_crypto_config_supported_natively(struct block_device *bdev, + const struct blk_crypto_config *cfg) +{ + return __blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, + cfg); +} + /* * Check if bios with @cfg can be en/decrypted by blk-crypto (i.e. either the * request queue it's submitted to supports inline crypto, or the @@ -361,8 +366,7 @@ bool blk_crypto_config_supported(struct block_device *bdev, const struct blk_crypto_config *cfg) { return IS_ENABLED(CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK) || - __blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, - cfg); + blk_crypto_config_supported_natively(bdev, cfg); } /** @@ -383,8 +387,7 @@ bool blk_crypto_config_supported(struct block_device *bdev, int blk_crypto_start_using_key(struct block_device *bdev, const struct blk_crypto_key *key) { - if (__blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, - &key->crypto_cfg)) + if (blk_crypto_config_supported_natively(bdev, &key->crypto_cfg)) return 0; return blk_crypto_fallback_start_using_mode(key->crypto_cfg.crypto_mode); } @@ -407,7 +410,7 @@ int blk_crypto_evict_key(struct block_device *bdev, { struct request_queue *q = bdev_get_queue(bdev); - if (__blk_crypto_cfg_supported(q->crypto_profile, &key->crypto_cfg)) + if (blk_crypto_config_supported_natively(bdev, &key->crypto_cfg)) return __blk_crypto_evict_key(q->crypto_profile, key); /* diff --git a/fs/crypto/inline_crypt.c b/fs/crypto/inline_crypt.c index 55c4d8c23d30d..8bfb3ce864766 100644 --- a/fs/crypto/inline_crypt.c +++ b/fs/crypto/inline_crypt.c @@ -12,7 +12,7 @@ * provides the key and IV to use. */ -#include <linux/blk-crypto-profile.h> +#include <linux/blk-crypto.h> #include <linux/blkdev.h> #include <linux/buffer_head.h> #include <linux/sched/mm.h> @@ -77,10 +77,8 @@ static void fscrypt_log_blk_crypto_impl(struct fscrypt_mode *mode, unsigned int i; for (i = 0; i < num_devs; i++) { - struct request_queue *q = bdev_get_queue(devs[i]); - if (!IS_ENABLED(CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK) || - __blk_crypto_cfg_supported(q->crypto_profile, cfg)) { + blk_crypto_config_supported_natively(devs[i], cfg)) { if (!xchg(&mode->logged_blk_crypto_native, 1)) pr_info("fscrypt: %s using blk-crypto (native)\n", mode->friendly_name); diff --git a/include/linux/blk-crypto.h b/include/linux/blk-crypto.h index b314e2febcaf5..1271ff39ab162 100644 --- a/include/linux/blk-crypto.h +++ b/include/linux/blk-crypto.h @@ -100,6 +100,8 @@ int blk_crypto_start_using_key(struct block_device *bdev, int blk_crypto_evict_key(struct block_device *bdev, const struct blk_crypto_key *key); +bool blk_crypto_config_supported_natively(struct block_device *bdev, + const struct blk_crypto_config *cfg); bool blk_crypto_config_supported(struct block_device *bdev, const struct blk_crypto_config *cfg); -- 2.30.2 -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH 2/3] blk-crypto: add a blk_crypto_config_supported_natively helper @ 2022-11-07 14:42 ` Christoph Hellwig 0 siblings, 0 replies; 18+ messages in thread From: Christoph Hellwig @ 2022-11-07 14:42 UTC (permalink / raw) To: Jens Axboe Cc: Mike Snitzer, Theodore Y. Ts'o, Jaegeuk Kim, Eric Biggers, dm-devel, linux-block, linux-fscrypt Add a blk_crypto_cfg_supported helper that wraps __blk_crypto_cfg_supported to retreive the crypto_profile from the request queue. With this fscrypt can stop including blk-crypto-profile.h and rely on the public consumer interface in blk-crypto.h. Signed-off-by: Christoph Hellwig <hch@lst.de> --- block/blk-crypto.c | 21 ++++++++++++--------- fs/crypto/inline_crypt.c | 6 ++---- include/linux/blk-crypto.h | 2 ++ 3 files changed, 16 insertions(+), 13 deletions(-) diff --git a/block/blk-crypto.c b/block/blk-crypto.c index 0e0c2fc56c428..ceb5a4c8f0306 100644 --- a/block/blk-crypto.c +++ b/block/blk-crypto.c @@ -267,7 +267,6 @@ bool __blk_crypto_bio_prep(struct bio **bio_ptr) { struct bio *bio = *bio_ptr; const struct blk_crypto_key *bc_key = bio->bi_crypt_context->bc_key; - struct blk_crypto_profile *profile; /* Error if bio has no data. */ if (WARN_ON_ONCE(!bio_has_data(bio))) { @@ -284,10 +283,9 @@ bool __blk_crypto_bio_prep(struct bio **bio_ptr) * Success if device supports the encryption context, or if we succeeded * in falling back to the crypto API. */ - profile = bdev_get_queue(bio->bi_bdev)->crypto_profile; - if (__blk_crypto_cfg_supported(profile, &bc_key->crypto_cfg)) + if (blk_crypto_config_supported_natively(bio->bi_bdev, + &bc_key->crypto_cfg)) return true; - if (blk_crypto_fallback_bio_prep(bio_ptr)) return true; fail: @@ -352,6 +350,13 @@ int blk_crypto_init_key(struct blk_crypto_key *blk_key, const u8 *raw_key, return 0; } +bool blk_crypto_config_supported_natively(struct block_device *bdev, + const struct blk_crypto_config *cfg) +{ + return __blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, + cfg); +} + /* * Check if bios with @cfg can be en/decrypted by blk-crypto (i.e. either the * request queue it's submitted to supports inline crypto, or the @@ -361,8 +366,7 @@ bool blk_crypto_config_supported(struct block_device *bdev, const struct blk_crypto_config *cfg) { return IS_ENABLED(CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK) || - __blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, - cfg); + blk_crypto_config_supported_natively(bdev, cfg); } /** @@ -383,8 +387,7 @@ bool blk_crypto_config_supported(struct block_device *bdev, int blk_crypto_start_using_key(struct block_device *bdev, const struct blk_crypto_key *key) { - if (__blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, - &key->crypto_cfg)) + if (blk_crypto_config_supported_natively(bdev, &key->crypto_cfg)) return 0; return blk_crypto_fallback_start_using_mode(key->crypto_cfg.crypto_mode); } @@ -407,7 +410,7 @@ int blk_crypto_evict_key(struct block_device *bdev, { struct request_queue *q = bdev_get_queue(bdev); - if (__blk_crypto_cfg_supported(q->crypto_profile, &key->crypto_cfg)) + if (blk_crypto_config_supported_natively(bdev, &key->crypto_cfg)) return __blk_crypto_evict_key(q->crypto_profile, key); /* diff --git a/fs/crypto/inline_crypt.c b/fs/crypto/inline_crypt.c index 55c4d8c23d30d..8bfb3ce864766 100644 --- a/fs/crypto/inline_crypt.c +++ b/fs/crypto/inline_crypt.c @@ -12,7 +12,7 @@ * provides the key and IV to use. */ -#include <linux/blk-crypto-profile.h> +#include <linux/blk-crypto.h> #include <linux/blkdev.h> #include <linux/buffer_head.h> #include <linux/sched/mm.h> @@ -77,10 +77,8 @@ static void fscrypt_log_blk_crypto_impl(struct fscrypt_mode *mode, unsigned int i; for (i = 0; i < num_devs; i++) { - struct request_queue *q = bdev_get_queue(devs[i]); - if (!IS_ENABLED(CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK) || - __blk_crypto_cfg_supported(q->crypto_profile, cfg)) { + blk_crypto_config_supported_natively(devs[i], cfg)) { if (!xchg(&mode->logged_blk_crypto_native, 1)) pr_info("fscrypt: %s using blk-crypto (native)\n", mode->friendly_name); diff --git a/include/linux/blk-crypto.h b/include/linux/blk-crypto.h index b314e2febcaf5..1271ff39ab162 100644 --- a/include/linux/blk-crypto.h +++ b/include/linux/blk-crypto.h @@ -100,6 +100,8 @@ int blk_crypto_start_using_key(struct block_device *bdev, int blk_crypto_evict_key(struct block_device *bdev, const struct blk_crypto_key *key); +bool blk_crypto_config_supported_natively(struct block_device *bdev, + const struct blk_crypto_config *cfg); bool blk_crypto_config_supported(struct block_device *bdev, const struct blk_crypto_config *cfg); -- 2.30.2 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [dm-devel] [PATCH 2/3] blk-crypto: add a blk_crypto_config_supported_natively helper 2022-11-07 14:42 ` Christoph Hellwig @ 2022-11-07 20:18 ` Eric Biggers -1 siblings, 0 replies; 18+ messages in thread From: Eric Biggers @ 2022-11-07 20:18 UTC (permalink / raw) To: Christoph Hellwig Cc: Jens Axboe, Theodore Y. Ts'o, Mike Snitzer, linux-fscrypt, linux-block, dm-devel, Jaegeuk Kim On Mon, Nov 07, 2022 at 03:42:28PM +0100, Christoph Hellwig wrote: > Add a blk_crypto_cfg_supported helper that wraps s/blk_crypto_cfg_supported/blk_crypto_config_supported_natively/ > __blk_crypto_cfg_supported to retreive the crypto_profile from the s/retreive/retrieve/. checkpatch warns about this. Otherwise this patch look good, thanks! - Eric -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/3] blk-crypto: add a blk_crypto_config_supported_natively helper @ 2022-11-07 20:18 ` Eric Biggers 0 siblings, 0 replies; 18+ messages in thread From: Eric Biggers @ 2022-11-07 20:18 UTC (permalink / raw) To: Christoph Hellwig Cc: Jens Axboe, Mike Snitzer, Theodore Y. Ts'o, Jaegeuk Kim, dm-devel, linux-block, linux-fscrypt On Mon, Nov 07, 2022 at 03:42:28PM +0100, Christoph Hellwig wrote: > Add a blk_crypto_cfg_supported helper that wraps s/blk_crypto_cfg_supported/blk_crypto_config_supported_natively/ > __blk_crypto_cfg_supported to retreive the crypto_profile from the s/retreive/retrieve/. checkpatch warns about this. Otherwise this patch look good, thanks! - Eric ^ permalink raw reply [flat|nested] 18+ messages in thread
* [dm-devel] [PATCH 3/3] blk-crypto: move __blk_crypto_cfg_supported to blk-crypto-internal.h 2022-11-07 14:42 ` Christoph Hellwig @ 2022-11-07 14:42 ` Christoph Hellwig -1 siblings, 0 replies; 18+ messages in thread From: Christoph Hellwig @ 2022-11-07 14:42 UTC (permalink / raw) To: Jens Axboe Cc: linux-block, Theodore Y. Ts'o, Mike Snitzer, linux-fscrypt, Eric Biggers, dm-devel, Jaegeuk Kim __blk_crypto_cfg_supported is only used internally by the blk-crypto code now, so move it out of the public header. Signed-off-by: Christoph Hellwig <hch@lst.de> --- block/blk-crypto-internal.h | 3 +++ include/linux/blk-crypto-profile.h | 3 --- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/block/blk-crypto-internal.h b/block/blk-crypto-internal.h index e6818ffaddbf8..c587b3e1886c9 100644 --- a/block/blk-crypto-internal.h +++ b/block/blk-crypto-internal.h @@ -19,6 +19,9 @@ struct blk_crypto_mode { extern const struct blk_crypto_mode blk_crypto_modes[]; +bool __blk_crypto_cfg_supported(struct blk_crypto_profile *profile, + const struct blk_crypto_config *cfg); + #ifdef CONFIG_BLK_INLINE_ENCRYPTION int blk_crypto_sysfs_register(struct request_queue *q); diff --git a/include/linux/blk-crypto-profile.h b/include/linux/blk-crypto-profile.h index bbab65bd54288..e990ec9b32aa4 100644 --- a/include/linux/blk-crypto-profile.h +++ b/include/linux/blk-crypto-profile.h @@ -144,9 +144,6 @@ blk_status_t blk_crypto_get_keyslot(struct blk_crypto_profile *profile, void blk_crypto_put_keyslot(struct blk_crypto_keyslot *slot); -bool __blk_crypto_cfg_supported(struct blk_crypto_profile *profile, - const struct blk_crypto_config *cfg); - int __blk_crypto_evict_key(struct blk_crypto_profile *profile, const struct blk_crypto_key *key); -- 2.30.2 -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH 3/3] blk-crypto: move __blk_crypto_cfg_supported to blk-crypto-internal.h @ 2022-11-07 14:42 ` Christoph Hellwig 0 siblings, 0 replies; 18+ messages in thread From: Christoph Hellwig @ 2022-11-07 14:42 UTC (permalink / raw) To: Jens Axboe Cc: Mike Snitzer, Theodore Y. Ts'o, Jaegeuk Kim, Eric Biggers, dm-devel, linux-block, linux-fscrypt __blk_crypto_cfg_supported is only used internally by the blk-crypto code now, so move it out of the public header. Signed-off-by: Christoph Hellwig <hch@lst.de> --- block/blk-crypto-internal.h | 3 +++ include/linux/blk-crypto-profile.h | 3 --- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/block/blk-crypto-internal.h b/block/blk-crypto-internal.h index e6818ffaddbf8..c587b3e1886c9 100644 --- a/block/blk-crypto-internal.h +++ b/block/blk-crypto-internal.h @@ -19,6 +19,9 @@ struct blk_crypto_mode { extern const struct blk_crypto_mode blk_crypto_modes[]; +bool __blk_crypto_cfg_supported(struct blk_crypto_profile *profile, + const struct blk_crypto_config *cfg); + #ifdef CONFIG_BLK_INLINE_ENCRYPTION int blk_crypto_sysfs_register(struct request_queue *q); diff --git a/include/linux/blk-crypto-profile.h b/include/linux/blk-crypto-profile.h index bbab65bd54288..e990ec9b32aa4 100644 --- a/include/linux/blk-crypto-profile.h +++ b/include/linux/blk-crypto-profile.h @@ -144,9 +144,6 @@ blk_status_t blk_crypto_get_keyslot(struct blk_crypto_profile *profile, void blk_crypto_put_keyslot(struct blk_crypto_keyslot *slot); -bool __blk_crypto_cfg_supported(struct blk_crypto_profile *profile, - const struct blk_crypto_config *cfg); - int __blk_crypto_evict_key(struct blk_crypto_profile *profile, const struct blk_crypto_key *key); -- 2.30.2 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [dm-devel] [PATCH 3/3] blk-crypto: move __blk_crypto_cfg_supported to blk-crypto-internal.h 2022-11-07 14:42 ` Christoph Hellwig @ 2022-11-07 20:23 ` Eric Biggers -1 siblings, 0 replies; 18+ messages in thread From: Eric Biggers @ 2022-11-07 20:23 UTC (permalink / raw) To: Christoph Hellwig Cc: Jens Axboe, Theodore Y. Ts'o, Mike Snitzer, linux-fscrypt, linux-block, dm-devel, Jaegeuk Kim On Mon, Nov 07, 2022 at 03:42:29PM +0100, Christoph Hellwig wrote: > __blk_crypto_cfg_supported is only used internally by the blk-crypto > code now, so move it out of the public header. "public header" is ambiguous here. blk-crypto.h is the "public header" for upper layers, but blk-crypto-profile.h is the "public header" for drivers. Maybe write "blk-crypto-profile.h, which is included by drivers". > diff --git a/block/blk-crypto-internal.h b/block/blk-crypto-internal.h > index e6818ffaddbf8..c587b3e1886c9 100644 > --- a/block/blk-crypto-internal.h > +++ b/block/blk-crypto-internal.h > @@ -19,6 +19,9 @@ struct blk_crypto_mode { > > extern const struct blk_crypto_mode blk_crypto_modes[]; > > +bool __blk_crypto_cfg_supported(struct blk_crypto_profile *profile, > + const struct blk_crypto_config *cfg); > + > #ifdef CONFIG_BLK_INLINE_ENCRYPTION It should go in the '#ifdef CONFIG_BLK_INLINE_ENCRYPTION' section. > diff --git a/include/linux/blk-crypto-profile.h b/include/linux/blk-crypto-profile.h > index bbab65bd54288..e990ec9b32aa4 100644 > --- a/include/linux/blk-crypto-profile.h > +++ b/include/linux/blk-crypto-profile.h > @@ -144,9 +144,6 @@ blk_status_t blk_crypto_get_keyslot(struct blk_crypto_profile *profile, > > void blk_crypto_put_keyslot(struct blk_crypto_keyslot *slot); > > -bool __blk_crypto_cfg_supported(struct blk_crypto_profile *profile, > - const struct blk_crypto_config *cfg); > - > int __blk_crypto_evict_key(struct blk_crypto_profile *profile, > const struct blk_crypto_key *key); Otherwise I guess this patch is fine. The exact same argument would also apply to blk_crypto_get_keyslot(), blk_crypto_put_keyslot(), and __blk_crypto_evict_key(), though. It might be worth handling them all in one patch. - Eric -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] blk-crypto: move __blk_crypto_cfg_supported to blk-crypto-internal.h @ 2022-11-07 20:23 ` Eric Biggers 0 siblings, 0 replies; 18+ messages in thread From: Eric Biggers @ 2022-11-07 20:23 UTC (permalink / raw) To: Christoph Hellwig Cc: Jens Axboe, Mike Snitzer, Theodore Y. Ts'o, Jaegeuk Kim, dm-devel, linux-block, linux-fscrypt On Mon, Nov 07, 2022 at 03:42:29PM +0100, Christoph Hellwig wrote: > __blk_crypto_cfg_supported is only used internally by the blk-crypto > code now, so move it out of the public header. "public header" is ambiguous here. blk-crypto.h is the "public header" for upper layers, but blk-crypto-profile.h is the "public header" for drivers. Maybe write "blk-crypto-profile.h, which is included by drivers". > diff --git a/block/blk-crypto-internal.h b/block/blk-crypto-internal.h > index e6818ffaddbf8..c587b3e1886c9 100644 > --- a/block/blk-crypto-internal.h > +++ b/block/blk-crypto-internal.h > @@ -19,6 +19,9 @@ struct blk_crypto_mode { > > extern const struct blk_crypto_mode blk_crypto_modes[]; > > +bool __blk_crypto_cfg_supported(struct blk_crypto_profile *profile, > + const struct blk_crypto_config *cfg); > + > #ifdef CONFIG_BLK_INLINE_ENCRYPTION It should go in the '#ifdef CONFIG_BLK_INLINE_ENCRYPTION' section. > diff --git a/include/linux/blk-crypto-profile.h b/include/linux/blk-crypto-profile.h > index bbab65bd54288..e990ec9b32aa4 100644 > --- a/include/linux/blk-crypto-profile.h > +++ b/include/linux/blk-crypto-profile.h > @@ -144,9 +144,6 @@ blk_status_t blk_crypto_get_keyslot(struct blk_crypto_profile *profile, > > void blk_crypto_put_keyslot(struct blk_crypto_keyslot *slot); > > -bool __blk_crypto_cfg_supported(struct blk_crypto_profile *profile, > - const struct blk_crypto_config *cfg); > - > int __blk_crypto_evict_key(struct blk_crypto_profile *profile, > const struct blk_crypto_key *key); Otherwise I guess this patch is fine. The exact same argument would also apply to blk_crypto_get_keyslot(), blk_crypto_put_keyslot(), and __blk_crypto_evict_key(), though. It might be worth handling them all in one patch. - Eric ^ permalink raw reply [flat|nested] 18+ messages in thread
* [dm-devel] pass a struct block_device to the blk-crypto interfaces v3 @ 2022-11-14 4:29 Christoph Hellwig 2022-11-14 4:29 ` [dm-devel] [PATCH 1/3] blk-crypto: don't use struct request_queue for public interfaces Christoph Hellwig 0 siblings, 1 reply; 18+ messages in thread From: Christoph Hellwig @ 2022-11-14 4:29 UTC (permalink / raw) To: Jens Axboe Cc: linux-block, Theodore Y. Ts'o, Mike Snitzer, linux-fscrypt, Eric Biggers, dm-devel, Jaegeuk Kim Hi all, this series switches the blk-crypto interfaces to take block_device arguments instead of request_queues, and with that finishes off the project to hide struct request_queue from file systems. Changes since v2: - update a few comments - fix a whitespace error - remove now unused forward declarations - fix spelling errors an not precise enough wording in commit messages - move a few more declarations around inside or between headers Changes since v1: - keep using request_queue in the Documentation for driver interfaces - rename to blk_crypto_cfg_supported to blk_crypto_config_supported_natively and move it to blk-crypto.[ch] - mark __blk_crypto_cfg_supported private Diffstat: Documentation/block/inline-encryption.rst | 12 ++++----- block/blk-crypto-internal.h | 12 +++++++++ block/blk-crypto.c | 37 +++++++++++++++++------------- drivers/md/dm-table.c | 2 - fs/crypto/inline_crypt.c | 14 ++++------- include/linux/blk-crypto-profile.h | 12 --------- include/linux/blk-crypto.h | 13 ++++------ 7 files changed, 52 insertions(+), 50 deletions(-) -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* [dm-devel] [PATCH 1/3] blk-crypto: don't use struct request_queue for public interfaces 2022-11-14 4:29 [dm-devel] pass a struct block_device to the blk-crypto interfaces v3 Christoph Hellwig @ 2022-11-14 4:29 ` Christoph Hellwig 2022-11-16 3:10 ` Eric Biggers 0 siblings, 1 reply; 18+ messages in thread From: Christoph Hellwig @ 2022-11-14 4:29 UTC (permalink / raw) To: Jens Axboe Cc: linux-block, Theodore Y. Ts'o, Mike Snitzer, linux-fscrypt, Eric Biggers, dm-devel, Jaegeuk Kim Switch all public blk-crypto interfaces to use struct block_device arguments to specify the device they operate on instead of th request_queue, which is a block layer implementation detail. Signed-off-by: Christoph Hellwig <hch@lst.de> --- Documentation/block/inline-encryption.rst | 12 ++++++------ block/blk-crypto.c | 24 +++++++++++++---------- drivers/md/dm-table.c | 2 +- fs/crypto/inline_crypt.c | 8 +++----- include/linux/blk-crypto.h | 11 ++++------- 5 files changed, 28 insertions(+), 29 deletions(-) diff --git a/Documentation/block/inline-encryption.rst b/Documentation/block/inline-encryption.rst index 4d151fbe20583..f9bf18ea65093 100644 --- a/Documentation/block/inline-encryption.rst +++ b/Documentation/block/inline-encryption.rst @@ -142,7 +142,7 @@ Therefore, we also introduce *blk-crypto-fallback*, which is an implementation of inline encryption using the kernel crypto API. blk-crypto-fallback is built into the block layer, so it works on any block device without any special setup. Essentially, when a bio with an encryption context is submitted to a -request_queue that doesn't support that encryption context, the block layer will +block_device that doesn't support that encryption context, the block layer will handle en/decryption of the bio using blk-crypto-fallback. For encryption, the data cannot be encrypted in-place, as callers usually rely @@ -187,7 +187,7 @@ API presented to users of the block layer ``blk_crypto_config_supported()`` allows users to check ahead of time whether inline encryption with particular crypto settings will work on a particular -request_queue -- either via hardware or via blk-crypto-fallback. This function +block_device -- either via hardware or via blk-crypto-fallback. This function takes in a ``struct blk_crypto_config`` which is like blk_crypto_key, but omits the actual bytes of the key and instead just contains the algorithm, data unit size, etc. This function can be useful if blk-crypto-fallback is disabled. @@ -195,7 +195,7 @@ size, etc. This function can be useful if blk-crypto-fallback is disabled. ``blk_crypto_init_key()`` allows users to initialize a blk_crypto_key. Users must call ``blk_crypto_start_using_key()`` before actually starting to use -a blk_crypto_key on a request_queue (even if ``blk_crypto_config_supported()`` +a blk_crypto_key on a block_device (even if ``blk_crypto_config_supported()`` was called earlier). This is needed to initialize blk-crypto-fallback if it will be needed. This must not be called from the data path, as this may have to allocate resources, which may deadlock in that case. @@ -207,7 +207,7 @@ for en/decryption. Users don't need to worry about freeing the bio_crypt_ctx later, as that happens automatically when the bio is freed or reset. Finally, when done using inline encryption with a blk_crypto_key on a -request_queue, users must call ``blk_crypto_evict_key()``. This ensures that +block_device, users must call ``blk_crypto_evict_key()``. This ensures that the key is evicted from all keyslots it may be programmed into and unlinked from any kernel data structures it may be linked into. @@ -221,9 +221,9 @@ as follows: 5. ``blk_crypto_evict_key()`` (after all I/O has completed) 6. Zeroize the blk_crypto_key (this has no dedicated function) -If a blk_crypto_key is being used on multiple request_queues, then +If a blk_crypto_key is being used on multiple block_devices, then ``blk_crypto_config_supported()`` (if used), ``blk_crypto_start_using_key()``, -and ``blk_crypto_evict_key()`` must be called on each request_queue. +and ``blk_crypto_evict_key()`` must be called on each block_device. API presented to device drivers =============================== diff --git a/block/blk-crypto.c b/block/blk-crypto.c index a496aaef85ba4..0047436b63371 100644 --- a/block/blk-crypto.c +++ b/block/blk-crypto.c @@ -354,20 +354,21 @@ int blk_crypto_init_key(struct blk_crypto_key *blk_key, const u8 *raw_key, /* * Check if bios with @cfg can be en/decrypted by blk-crypto (i.e. either the - * request queue it's submitted to supports inline crypto, or the + * block_device it's submitted to supports inline crypto, or the * blk-crypto-fallback is enabled and supports the cfg). */ -bool blk_crypto_config_supported(struct request_queue *q, +bool blk_crypto_config_supported(struct block_device *bdev, const struct blk_crypto_config *cfg) { return IS_ENABLED(CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK) || - __blk_crypto_cfg_supported(q->crypto_profile, cfg); + __blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, + cfg); } /** * blk_crypto_start_using_key() - Start using a blk_crypto_key on a device + * @bdev: block device to operate on * @key: A key to use on the device - * @q: the request queue for the device * * Upper layers must call this function to ensure that either the hardware * supports the key's crypto settings, or the crypto API fallback has transforms @@ -379,10 +380,11 @@ bool blk_crypto_config_supported(struct request_queue *q, * blk-crypto-fallback is either disabled or the needed algorithm * is disabled in the crypto API; or another -errno code. */ -int blk_crypto_start_using_key(const struct blk_crypto_key *key, - struct request_queue *q) +int blk_crypto_start_using_key(struct block_device *bdev, + const struct blk_crypto_key *key) { - if (__blk_crypto_cfg_supported(q->crypto_profile, &key->crypto_cfg)) + if (__blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, + &key->crypto_cfg)) return 0; return blk_crypto_fallback_start_using_mode(key->crypto_cfg.crypto_mode); } @@ -390,7 +392,7 @@ int blk_crypto_start_using_key(const struct blk_crypto_key *key, /** * blk_crypto_evict_key() - Evict a key from any inline encryption hardware * it may have been programmed into - * @q: The request queue who's associated inline encryption hardware this key + * @bdev: The block_device who's associated inline encryption hardware this key * might have been programmed into * @key: The key to evict * @@ -400,14 +402,16 @@ int blk_crypto_start_using_key(const struct blk_crypto_key *key, * * Return: 0 on success or if the key wasn't in any keyslot; -errno on error. */ -int blk_crypto_evict_key(struct request_queue *q, +int blk_crypto_evict_key(struct block_device *bdev, const struct blk_crypto_key *key) { + struct request_queue *q = bdev_get_queue(bdev); + if (__blk_crypto_cfg_supported(q->crypto_profile, &key->crypto_cfg)) return __blk_crypto_evict_key(q->crypto_profile, key); /* - * If the request_queue didn't support the key, then blk-crypto-fallback + * If the block_device didn't support the key, then blk-crypto-fallback * may have been used, so try to evict the key from blk-crypto-fallback. */ return blk_crypto_fallback_evict_key(key); diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c index 078da18bb86d8..8541d5688f3a6 100644 --- a/drivers/md/dm-table.c +++ b/drivers/md/dm-table.c @@ -1215,7 +1215,7 @@ static int dm_keyslot_evict_callback(struct dm_target *ti, struct dm_dev *dev, struct dm_keyslot_evict_args *args = data; int err; - err = blk_crypto_evict_key(bdev_get_queue(dev->bdev), args->key); + err = blk_crypto_evict_key(dev->bdev, args->key); if (!args->err) args->err = err; /* Always try to evict the key from all devices. */ diff --git a/fs/crypto/inline_crypt.c b/fs/crypto/inline_crypt.c index cea8b14007e6a..55c4d8c23d30d 100644 --- a/fs/crypto/inline_crypt.c +++ b/fs/crypto/inline_crypt.c @@ -139,8 +139,7 @@ int fscrypt_select_encryption_impl(struct fscrypt_info *ci) return PTR_ERR(devs); for (i = 0; i < num_devs; i++) { - if (!blk_crypto_config_supported(bdev_get_queue(devs[i]), - &crypto_cfg)) + if (!blk_crypto_config_supported(devs[i], &crypto_cfg)) goto out_free_devs; } @@ -184,8 +183,7 @@ int fscrypt_prepare_inline_crypt_key(struct fscrypt_prepared_key *prep_key, goto fail; } for (i = 0; i < num_devs; i++) { - err = blk_crypto_start_using_key(blk_key, - bdev_get_queue(devs[i])); + err = blk_crypto_start_using_key(devs[i], blk_key); if (err) break; } @@ -224,7 +222,7 @@ void fscrypt_destroy_inline_crypt_key(struct super_block *sb, devs = fscrypt_get_devices(sb, &num_devs); if (!IS_ERR(devs)) { for (i = 0; i < num_devs; i++) - blk_crypto_evict_key(bdev_get_queue(devs[i]), blk_key); + blk_crypto_evict_key(devs[i], blk_key); kfree(devs); } kfree_sensitive(blk_key); diff --git a/include/linux/blk-crypto.h b/include/linux/blk-crypto.h index 69b24fe92cbf1..561ca92e204d5 100644 --- a/include/linux/blk-crypto.h +++ b/include/linux/blk-crypto.h @@ -71,9 +71,6 @@ struct bio_crypt_ctx { #include <linux/blk_types.h> #include <linux/blkdev.h> -struct request; -struct request_queue; - #ifdef CONFIG_BLK_INLINE_ENCRYPTION static inline bool bio_has_crypt_ctx(struct bio *bio) @@ -94,13 +91,13 @@ int blk_crypto_init_key(struct blk_crypto_key *blk_key, const u8 *raw_key, unsigned int dun_bytes, unsigned int data_unit_size); -int blk_crypto_start_using_key(const struct blk_crypto_key *key, - struct request_queue *q); +int blk_crypto_start_using_key(struct block_device *bdev, + const struct blk_crypto_key *key); -int blk_crypto_evict_key(struct request_queue *q, +int blk_crypto_evict_key(struct block_device *bdev, const struct blk_crypto_key *key); -bool blk_crypto_config_supported(struct request_queue *q, +bool blk_crypto_config_supported(struct block_device *bdev, const struct blk_crypto_config *cfg); #else /* CONFIG_BLK_INLINE_ENCRYPTION */ -- 2.30.2 -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [dm-devel] [PATCH 1/3] blk-crypto: don't use struct request_queue for public interfaces 2022-11-14 4:29 ` [dm-devel] [PATCH 1/3] blk-crypto: don't use struct request_queue for public interfaces Christoph Hellwig @ 2022-11-16 3:10 ` Eric Biggers 0 siblings, 0 replies; 18+ messages in thread From: Eric Biggers @ 2022-11-16 3:10 UTC (permalink / raw) To: Christoph Hellwig Cc: Jens Axboe, Theodore Y. Ts'o, Mike Snitzer, linux-fscrypt, linux-block, dm-devel, Jaegeuk Kim On Mon, Nov 14, 2022 at 05:29:42AM +0100, Christoph Hellwig wrote: > Switch all public blk-crypto interfaces to use struct block_device > arguments to specify the device they operate on instead of th > request_queue, which is a block layer implementation detail. > > Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Eric Biggers <ebiggers@google.com> - Eric -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2022-11-16 3:11 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-11-07 14:42 [dm-devel] pass a struct block_device to the blk-crypto interfaces v2 Christoph Hellwig 2022-11-07 14:42 ` Christoph Hellwig 2022-11-07 14:42 ` [dm-devel] [PATCH 1/3] blk-crypto: don't use struct request_queue for public interfaces Christoph Hellwig 2022-11-07 14:42 ` Christoph Hellwig 2022-11-07 20:16 ` [dm-devel] " Eric Biggers 2022-11-07 20:16 ` Eric Biggers 2022-11-09 13:14 ` [dm-devel] " Christoph Hellwig 2022-11-09 13:14 ` Christoph Hellwig 2022-11-07 14:42 ` [dm-devel] [PATCH 2/3] blk-crypto: add a blk_crypto_config_supported_natively helper Christoph Hellwig 2022-11-07 14:42 ` Christoph Hellwig 2022-11-07 20:18 ` [dm-devel] " Eric Biggers 2022-11-07 20:18 ` Eric Biggers 2022-11-07 14:42 ` [dm-devel] [PATCH 3/3] blk-crypto: move __blk_crypto_cfg_supported to blk-crypto-internal.h Christoph Hellwig 2022-11-07 14:42 ` Christoph Hellwig 2022-11-07 20:23 ` [dm-devel] " Eric Biggers 2022-11-07 20:23 ` Eric Biggers -- strict thread matches above, loose matches on Subject: below -- 2022-11-14 4:29 [dm-devel] pass a struct block_device to the blk-crypto interfaces v3 Christoph Hellwig 2022-11-14 4:29 ` [dm-devel] [PATCH 1/3] blk-crypto: don't use struct request_queue for public interfaces Christoph Hellwig 2022-11-16 3:10 ` Eric Biggers
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.