* pass a struct block_device to the blk-crypto interfaces @ 2022-11-04 5:46 ` Christoph Hellwig 0 siblings, 0 replies; 14+ messages in thread From: Christoph Hellwig @ 2022-11-04 5:46 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. Diffstat: Documentation/block/inline-encryption.rst | 24 ++++++++++++------------ block/blk-crypto-profile.c | 7 +++++++ block/blk-crypto.c | 25 ++++++++++++------------- drivers/md/dm-table.c | 2 +- fs/crypto/inline_crypt.c | 12 ++++-------- include/linux/blk-crypto-profile.h | 2 ++ include/linux/blk-crypto.h | 8 ++++---- 7 files changed, 42 insertions(+), 38 deletions(-) ^ permalink raw reply [flat|nested] 14+ messages in thread
* [dm-devel] pass a struct block_device to the blk-crypto interfaces @ 2022-11-04 5:46 ` Christoph Hellwig 0 siblings, 0 replies; 14+ messages in thread From: Christoph Hellwig @ 2022-11-04 5:46 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. Diffstat: Documentation/block/inline-encryption.rst | 24 ++++++++++++------------ block/blk-crypto-profile.c | 7 +++++++ block/blk-crypto.c | 25 ++++++++++++------------- drivers/md/dm-table.c | 2 +- fs/crypto/inline_crypt.c | 12 ++++-------- include/linux/blk-crypto-profile.h | 2 ++ include/linux/blk-crypto.h | 8 ++++---- 7 files changed, 42 insertions(+), 38 deletions(-) -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 1/2] blk-crypto: don't use struct request_queue for public interfaces 2022-11-04 5:46 ` [dm-devel] " Christoph Hellwig @ 2022-11-04 5:46 ` Christoph Hellwig -1 siblings, 0 replies; 14+ messages in thread From: Christoph Hellwig @ 2022-11-04 5:46 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 | 24 +++++++++++------------ 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, 32 insertions(+), 30 deletions(-) diff --git a/Documentation/block/inline-encryption.rst b/Documentation/block/inline-encryption.rst index 4d151fbe20583..168d465f65263 100644 --- a/Documentation/block/inline-encryption.rst +++ b/Documentation/block/inline-encryption.rst @@ -97,7 +97,7 @@ blk_crypto_profile serves as the way that drivers for inline encryption hardware advertise their crypto capabilities and provide certain functions (e.g., functions to program and evict keys) to upper layers. Each device driver that wants to support inline encryption will construct a blk_crypto_profile, then -associate it with the disk's request_queue. +associate it with the block device. The blk_crypto_profile also manages the hardware's keyslots, when applicable. This happens in the block layer, so that users of the block layer can just @@ -124,7 +124,7 @@ numbers. Only the encryption context for the first bio in a request is retained, since the remaining bios have been verified to be merge-compatible with the first bio. -To make it possible for inline encryption to work with request_queue based +To make it possible for inline encryption to work with struct request based layered devices, when a request is cloned, its encryption context is cloned as well. When the cloned request is submitted, it is then processed as usual; this includes getting a keyslot from the clone's target device if needed. @@ -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_devіce -- 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 =============================== @@ -242,7 +242,7 @@ hardware, e.g. how to program and evict keyslots. Most drivers will need to implement ``keyslot_program`` and ``keyslot_evict``. For details, see the comments for ``struct blk_crypto_ll_ops``. -Once the driver registers a blk_crypto_profile with a request_queue, I/O +Once the driver registers a blk_crypto_profile with a block_device, I/O requests the driver receives via that queue may have an encryption context. All encryption contexts will be compatible with the crypto capabilities declared in the blk_crypto_profile, so drivers don't need to worry about handling @@ -266,10 +266,10 @@ Finally, if the driver used ``blk_crypto_profile_init()`` instead of Layered Devices =============== -Request queue based layered devices like dm-rq that wish to support inline -encryption need to create their own blk_crypto_profile for their request_queue, +Request based layered devices like dm-rq that wish to support inline +encryption need to create their own blk_crypto_profile for their block_device, and expose whatever functionality they choose. When a layered device wants to -pass a clone of that request to another request_queue, blk-crypto will +pass a clone of that request to another block_device, blk-crypto will initialize and prepare the clone as necessary; see ``blk_crypto_insert_cloned_request()``. 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] 14+ messages in thread
* [dm-devel] [PATCH 1/2] blk-crypto: don't use struct request_queue for public interfaces @ 2022-11-04 5:46 ` Christoph Hellwig 0 siblings, 0 replies; 14+ messages in thread From: Christoph Hellwig @ 2022-11-04 5:46 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 | 24 +++++++++++------------ 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, 32 insertions(+), 30 deletions(-) diff --git a/Documentation/block/inline-encryption.rst b/Documentation/block/inline-encryption.rst index 4d151fbe20583..168d465f65263 100644 --- a/Documentation/block/inline-encryption.rst +++ b/Documentation/block/inline-encryption.rst @@ -97,7 +97,7 @@ blk_crypto_profile serves as the way that drivers for inline encryption hardware advertise their crypto capabilities and provide certain functions (e.g., functions to program and evict keys) to upper layers. Each device driver that wants to support inline encryption will construct a blk_crypto_profile, then -associate it with the disk's request_queue. +associate it with the block device. The blk_crypto_profile also manages the hardware's keyslots, when applicable. This happens in the block layer, so that users of the block layer can just @@ -124,7 +124,7 @@ numbers. Only the encryption context for the first bio in a request is retained, since the remaining bios have been verified to be merge-compatible with the first bio. -To make it possible for inline encryption to work with request_queue based +To make it possible for inline encryption to work with struct request based layered devices, when a request is cloned, its encryption context is cloned as well. When the cloned request is submitted, it is then processed as usual; this includes getting a keyslot from the clone's target device if needed. @@ -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_devіce -- 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 =============================== @@ -242,7 +242,7 @@ hardware, e.g. how to program and evict keyslots. Most drivers will need to implement ``keyslot_program`` and ``keyslot_evict``. For details, see the comments for ``struct blk_crypto_ll_ops``. -Once the driver registers a blk_crypto_profile with a request_queue, I/O +Once the driver registers a blk_crypto_profile with a block_device, I/O requests the driver receives via that queue may have an encryption context. All encryption contexts will be compatible with the crypto capabilities declared in the blk_crypto_profile, so drivers don't need to worry about handling @@ -266,10 +266,10 @@ Finally, if the driver used ``blk_crypto_profile_init()`` instead of Layered Devices =============== -Request queue based layered devices like dm-rq that wish to support inline -encryption need to create their own blk_crypto_profile for their request_queue, +Request based layered devices like dm-rq that wish to support inline +encryption need to create their own blk_crypto_profile for their block_device, and expose whatever functionality they choose. When a layered device wants to -pass a clone of that request to another request_queue, blk-crypto will +pass a clone of that request to another block_device, blk-crypto will initialize and prepare the clone as necessary; see ``blk_crypto_insert_cloned_request()``. 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] 14+ messages in thread
* Re: [PATCH 1/2] blk-crypto: don't use struct request_queue for public interfaces 2022-11-04 5:46 ` [dm-devel] " Christoph Hellwig @ 2022-11-04 7:28 ` Eric Biggers -1 siblings, 0 replies; 14+ messages in thread From: Eric Biggers @ 2022-11-04 7:28 UTC (permalink / raw) To: Christoph Hellwig Cc: Jens Axboe, Mike Snitzer, Theodore Y. Ts'o, Jaegeuk Kim, dm-devel, linux-block, linux-fscrypt On Fri, Nov 04, 2022 at 06:46:20AM +0100, Christoph Hellwig wrote: > Each device driver that > wants to support inline encryption will construct a blk_crypto_profile, then > -associate it with the disk's request_queue. > +associate it with the block device. > [...] > -Once the driver registers a blk_crypto_profile with a request_queue, I/O > +Once the driver registers a blk_crypto_profile with a block_device, I/O > requests the driver receives via that queue may have an encryption context. [...] > -Request queue based layered devices like dm-rq that wish to support inline > -encryption need to create their own blk_crypto_profile for their request_queue, > +Request based layered devices like dm-rq that wish to support inline > +encryption need to create their own blk_crypto_profile for their block_device, > and expose whatever functionality they choose. When a layered device wants to [...] Shouldn't the three places above still say request_queue, not block_device? They're talking about the driver. - Eric ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [dm-devel] [PATCH 1/2] blk-crypto: don't use struct request_queue for public interfaces @ 2022-11-04 7:28 ` Eric Biggers 0 siblings, 0 replies; 14+ messages in thread From: Eric Biggers @ 2022-11-04 7:28 UTC (permalink / raw) To: Christoph Hellwig Cc: Jens Axboe, Theodore Y. Ts'o, Mike Snitzer, linux-fscrypt, linux-block, dm-devel, Jaegeuk Kim On Fri, Nov 04, 2022 at 06:46:20AM +0100, Christoph Hellwig wrote: > Each device driver that > wants to support inline encryption will construct a blk_crypto_profile, then > -associate it with the disk's request_queue. > +associate it with the block device. > [...] > -Once the driver registers a blk_crypto_profile with a request_queue, I/O > +Once the driver registers a blk_crypto_profile with a block_device, I/O > requests the driver receives via that queue may have an encryption context. [...] > -Request queue based layered devices like dm-rq that wish to support inline > -encryption need to create their own blk_crypto_profile for their request_queue, > +Request based layered devices like dm-rq that wish to support inline > +encryption need to create their own blk_crypto_profile for their block_device, > and expose whatever functionality they choose. When a layered device wants to [...] Shouldn't the three places above still say request_queue, not block_device? They're talking about the driver. - Eric -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/2] blk-crypto: don't use struct request_queue for public interfaces 2022-11-04 7:28 ` [dm-devel] " Eric Biggers @ 2022-11-04 7:32 ` Christoph Hellwig -1 siblings, 0 replies; 14+ messages in thread From: Christoph Hellwig @ 2022-11-04 7:32 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 Fri, Nov 04, 2022 at 12:28:13AM -0700, Eric Biggers wrote: > Shouldn't the three places above still say request_queue, not block_device? > They're talking about the driver. Yes, probably. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [dm-devel] [PATCH 1/2] blk-crypto: don't use struct request_queue for public interfaces @ 2022-11-04 7:32 ` Christoph Hellwig 0 siblings, 0 replies; 14+ messages in thread From: Christoph Hellwig @ 2022-11-04 7:32 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 Fri, Nov 04, 2022 at 12:28:13AM -0700, Eric Biggers wrote: > Shouldn't the three places above still say request_queue, not block_device? > They're talking about the driver. Yes, probably. -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 2/2] blk-crypto: add a blk_crypto_cfg_supported helper 2022-11-04 5:46 ` [dm-devel] " Christoph Hellwig @ 2022-11-04 5:46 ` Christoph Hellwig -1 siblings, 0 replies; 14+ messages in thread From: Christoph Hellwig @ 2022-11-04 5:46 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. Signed-off-by: Christoph Hellwig <hch@lst.de> --- block/blk-crypto-profile.c | 7 +++++++ block/blk-crypto.c | 13 ++++--------- fs/crypto/inline_crypt.c | 4 +--- include/linux/blk-crypto-profile.h | 2 ++ 4 files changed, 14 insertions(+), 12 deletions(-) diff --git a/block/blk-crypto-profile.c b/block/blk-crypto-profile.c index 96c511967386d..e8a0a3457fa29 100644 --- a/block/blk-crypto-profile.c +++ b/block/blk-crypto-profile.c @@ -353,6 +353,13 @@ bool __blk_crypto_cfg_supported(struct blk_crypto_profile *profile, return true; } +bool blk_crypto_cfg_supported(struct block_device *bdev, + const struct blk_crypto_config *cfg) +{ + return __blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, + cfg); +} + /** * __blk_crypto_evict_key() - Evict a key from a device. * @profile: the crypto profile of the device diff --git a/block/blk-crypto.c b/block/blk-crypto.c index 0e0c2fc56c428..b4597d0e87546 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,8 @@ 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_cfg_supported(bio->bi_bdev, &bc_key->crypto_cfg)) return true; - if (blk_crypto_fallback_bio_prep(bio_ptr)) return true; fail: @@ -361,8 +358,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_cfg_supported(bdev, cfg); } /** @@ -383,8 +379,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_cfg_supported(bdev, &key->crypto_cfg)) return 0; return blk_crypto_fallback_start_using_mode(key->crypto_cfg.crypto_mode); } @@ -407,7 +402,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_cfg_supported(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..4034908743453 100644 --- a/fs/crypto/inline_crypt.c +++ b/fs/crypto/inline_crypt.c @@ -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_cfg_supported(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-profile.h b/include/linux/blk-crypto-profile.h index bbab65bd54288..a9ddf543c8a97 100644 --- a/include/linux/blk-crypto-profile.h +++ b/include/linux/blk-crypto-profile.h @@ -144,6 +144,8 @@ 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 block_device *bdev, + const struct blk_crypto_config *cfg); bool __blk_crypto_cfg_supported(struct blk_crypto_profile *profile, const struct blk_crypto_config *cfg); -- 2.30.2 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [dm-devel] [PATCH 2/2] blk-crypto: add a blk_crypto_cfg_supported helper @ 2022-11-04 5:46 ` Christoph Hellwig 0 siblings, 0 replies; 14+ messages in thread From: Christoph Hellwig @ 2022-11-04 5:46 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. Signed-off-by: Christoph Hellwig <hch@lst.de> --- block/blk-crypto-profile.c | 7 +++++++ block/blk-crypto.c | 13 ++++--------- fs/crypto/inline_crypt.c | 4 +--- include/linux/blk-crypto-profile.h | 2 ++ 4 files changed, 14 insertions(+), 12 deletions(-) diff --git a/block/blk-crypto-profile.c b/block/blk-crypto-profile.c index 96c511967386d..e8a0a3457fa29 100644 --- a/block/blk-crypto-profile.c +++ b/block/blk-crypto-profile.c @@ -353,6 +353,13 @@ bool __blk_crypto_cfg_supported(struct blk_crypto_profile *profile, return true; } +bool blk_crypto_cfg_supported(struct block_device *bdev, + const struct blk_crypto_config *cfg) +{ + return __blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, + cfg); +} + /** * __blk_crypto_evict_key() - Evict a key from a device. * @profile: the crypto profile of the device diff --git a/block/blk-crypto.c b/block/blk-crypto.c index 0e0c2fc56c428..b4597d0e87546 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,8 @@ 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_cfg_supported(bio->bi_bdev, &bc_key->crypto_cfg)) return true; - if (blk_crypto_fallback_bio_prep(bio_ptr)) return true; fail: @@ -361,8 +358,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_cfg_supported(bdev, cfg); } /** @@ -383,8 +379,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_cfg_supported(bdev, &key->crypto_cfg)) return 0; return blk_crypto_fallback_start_using_mode(key->crypto_cfg.crypto_mode); } @@ -407,7 +402,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_cfg_supported(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..4034908743453 100644 --- a/fs/crypto/inline_crypt.c +++ b/fs/crypto/inline_crypt.c @@ -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_cfg_supported(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-profile.h b/include/linux/blk-crypto-profile.h index bbab65bd54288..a9ddf543c8a97 100644 --- a/include/linux/blk-crypto-profile.h +++ b/include/linux/blk-crypto-profile.h @@ -144,6 +144,8 @@ 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 block_device *bdev, + const struct blk_crypto_config *cfg); bool __blk_crypto_cfg_supported(struct blk_crypto_profile *profile, 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] 14+ messages in thread
* Re: [PATCH 2/2] blk-crypto: add a blk_crypto_cfg_supported helper 2022-11-04 5:46 ` [dm-devel] " Christoph Hellwig @ 2022-11-04 7:23 ` Eric Biggers -1 siblings, 0 replies; 14+ messages in thread From: Eric Biggers @ 2022-11-04 7: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 Fri, Nov 04, 2022 at 06:46:21AM +0100, Christoph Hellwig wrote: > Add a blk_crypto_cfg_supported helper that wraps > __blk_crypto_cfg_supported to retreive the crypto_profile from the > request queue. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > block/blk-crypto-profile.c | 7 +++++++ > block/blk-crypto.c | 13 ++++--------- > fs/crypto/inline_crypt.c | 4 +--- > include/linux/blk-crypto-profile.h | 2 ++ > 4 files changed, 14 insertions(+), 12 deletions(-) > > diff --git a/block/blk-crypto-profile.c b/block/blk-crypto-profile.c > index 96c511967386d..e8a0a3457fa29 100644 > --- a/block/blk-crypto-profile.c > +++ b/block/blk-crypto-profile.c > @@ -353,6 +353,13 @@ bool __blk_crypto_cfg_supported(struct blk_crypto_profile *profile, > return true; > } > > +bool blk_crypto_cfg_supported(struct block_device *bdev, > + const struct blk_crypto_config *cfg) > +{ > + return __blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, > + cfg); > +} I think this part is too confusing, because there's already a function blk_crypto_config_supported() which does something slightly different. How about calling this blk_crypto_config_supported_natively() instead? It's kind of long, but it's much clearer. Also, it should be defined in blk-crypto.c, next to blk_crypto_config_supported(), and not in blk-crypto-profile.c. (And declared in blk-crypto.h, not blk-crypto-profile.h.) This would also make it so that fs/crypto/inline_crypt.c could go back to including blk-crypto.h instead of blk-crypto-profile.h. blk-crypto.h is supposed to be the interface to upper layers, not blk-crypto-profile.h. So, something like this: 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_config_supported_natively(bdev, cfg); } 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); } - Eric ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [dm-devel] [PATCH 2/2] blk-crypto: add a blk_crypto_cfg_supported helper @ 2022-11-04 7:23 ` Eric Biggers 0 siblings, 0 replies; 14+ messages in thread From: Eric Biggers @ 2022-11-04 7: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 Fri, Nov 04, 2022 at 06:46:21AM +0100, Christoph Hellwig wrote: > Add a blk_crypto_cfg_supported helper that wraps > __blk_crypto_cfg_supported to retreive the crypto_profile from the > request queue. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > block/blk-crypto-profile.c | 7 +++++++ > block/blk-crypto.c | 13 ++++--------- > fs/crypto/inline_crypt.c | 4 +--- > include/linux/blk-crypto-profile.h | 2 ++ > 4 files changed, 14 insertions(+), 12 deletions(-) > > diff --git a/block/blk-crypto-profile.c b/block/blk-crypto-profile.c > index 96c511967386d..e8a0a3457fa29 100644 > --- a/block/blk-crypto-profile.c > +++ b/block/blk-crypto-profile.c > @@ -353,6 +353,13 @@ bool __blk_crypto_cfg_supported(struct blk_crypto_profile *profile, > return true; > } > > +bool blk_crypto_cfg_supported(struct block_device *bdev, > + const struct blk_crypto_config *cfg) > +{ > + return __blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, > + cfg); > +} I think this part is too confusing, because there's already a function blk_crypto_config_supported() which does something slightly different. How about calling this blk_crypto_config_supported_natively() instead? It's kind of long, but it's much clearer. Also, it should be defined in blk-crypto.c, next to blk_crypto_config_supported(), and not in blk-crypto-profile.c. (And declared in blk-crypto.h, not blk-crypto-profile.h.) This would also make it so that fs/crypto/inline_crypt.c could go back to including blk-crypto.h instead of blk-crypto-profile.h. blk-crypto.h is supposed to be the interface to upper layers, not blk-crypto-profile.h. So, something like this: 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_config_supported_natively(bdev, cfg); } 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); } - Eric -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 2/2] blk-crypto: add a blk_crypto_cfg_supported helper 2022-11-04 7:23 ` [dm-devel] " Eric Biggers @ 2022-11-04 7:32 ` Christoph Hellwig -1 siblings, 0 replies; 14+ messages in thread From: Christoph Hellwig @ 2022-11-04 7:32 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 Fri, Nov 04, 2022 at 12:23:07AM -0700, Eric Biggers wrote: > > +bool blk_crypto_cfg_supported(struct block_device *bdev, > > + const struct blk_crypto_config *cfg) > > +{ > > + return __blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, > > + cfg); > > +} > > I think this part is too confusing, because there's already a function > blk_crypto_config_supported() which does something slightly different. > > How about calling this blk_crypto_config_supported_natively() instead? It's > kind of long, but it's much clearer. Fine with me. > Also, it should be defined in blk-crypto.c, next to > blk_crypto_config_supported(), and not in blk-crypto-profile.c. > (And declared in blk-crypto.h, not blk-crypto-profile.h.) Ok. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [dm-devel] [PATCH 2/2] blk-crypto: add a blk_crypto_cfg_supported helper @ 2022-11-04 7:32 ` Christoph Hellwig 0 siblings, 0 replies; 14+ messages in thread From: Christoph Hellwig @ 2022-11-04 7:32 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 Fri, Nov 04, 2022 at 12:23:07AM -0700, Eric Biggers wrote: > > +bool blk_crypto_cfg_supported(struct block_device *bdev, > > + const struct blk_crypto_config *cfg) > > +{ > > + return __blk_crypto_cfg_supported(bdev_get_queue(bdev)->crypto_profile, > > + cfg); > > +} > > I think this part is too confusing, because there's already a function > blk_crypto_config_supported() which does something slightly different. > > How about calling this blk_crypto_config_supported_natively() instead? It's > kind of long, but it's much clearer. Fine with me. > Also, it should be defined in blk-crypto.c, next to > blk_crypto_config_supported(), and not in blk-crypto-profile.c. > (And declared in blk-crypto.h, not blk-crypto-profile.h.) Ok. -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2022-11-04 7:36 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-11-04 5:46 pass a struct block_device to the blk-crypto interfaces Christoph Hellwig 2022-11-04 5:46 ` [dm-devel] " Christoph Hellwig 2022-11-04 5:46 ` [PATCH 1/2] blk-crypto: don't use struct request_queue for public interfaces Christoph Hellwig 2022-11-04 5:46 ` [dm-devel] " Christoph Hellwig 2022-11-04 7:28 ` Eric Biggers 2022-11-04 7:28 ` [dm-devel] " Eric Biggers 2022-11-04 7:32 ` Christoph Hellwig 2022-11-04 7:32 ` [dm-devel] " Christoph Hellwig 2022-11-04 5:46 ` [PATCH 2/2] blk-crypto: add a blk_crypto_cfg_supported helper Christoph Hellwig 2022-11-04 5:46 ` [dm-devel] " Christoph Hellwig 2022-11-04 7:23 ` Eric Biggers 2022-11-04 7:23 ` [dm-devel] " Eric Biggers 2022-11-04 7:32 ` Christoph Hellwig 2022-11-04 7:32 ` [dm-devel] " Christoph Hellwig
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.