On 3/12/2026 2:35 PM, Eric Biggers wrote: > On Wed, Mar 04, 2026 at 04:17:28AM -0800, Linlin Zhang wrote: >> Add a new DM flag, which means the inline crypto capabilities >> from underlying devices can be exposed to the DM device, and >> the DM device consumes these capabilities, rather pass through >> them to the upper layer. >> >> Signed-off-by: Linlin Zhang <[email protected]> >> --- >> drivers/md/dm-inlinecrypt.c | 2 +- >> drivers/md/dm-table.c | 3 ++- >> include/linux/device-mapper.h | 7 +++++++ >> 3 files changed, 10 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/md/dm-inlinecrypt.c b/drivers/md/dm-inlinecrypt.c >> index 251760da9f7e..eda56893d430 100644 >> --- a/drivers/md/dm-inlinecrypt.c >> +++ b/drivers/md/dm-inlinecrypt.c >> @@ -396,7 +396,7 @@ static struct target_type inlinecrypt_target = { >> * Do not set DM_TARGET_PASSES_CRYPTO, since dm-inlinecrypt consumes the >> * crypto capability itself. >> */ >> - .features = DM_TARGET_ZONED_HM, >> + .features = DM_TARGET_CONSUME_CRYPTO | DM_TARGET_ZONED_HM, >> .module = THIS_MODULE, >> .ctr = inlinecrypt_ctr, >> .dtr = inlinecrypt_dtr, >> diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c >> index 7be1d8dc8bdd..f0580935394a 100644 >> --- a/drivers/md/dm-table.c >> +++ b/drivers/md/dm-table.c >> @@ -1407,7 +1407,8 @@ static int dm_table_construct_crypto_profile(struct >> dm_table *t) >> for (i = 0; i < t->num_targets; i++) { >> struct dm_target *ti = dm_table_get_target(t, i); >> >> - if (!dm_target_passes_crypto(ti->type)) { >> + if (!dm_target_passes_crypto(ti->type) >> + && !dm_target_consume_crypto(ti->type)) { >> blk_crypto_intersect_capabilities(profile, NULL); >> break; >> } >> diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h >> index 38f625af6ab4..6abd1b4fcb76 100644 >> --- a/include/linux/device-mapper.h >> +++ b/include/linux/device-mapper.h >> @@ -306,6 +306,13 @@ struct target_type { >> #define dm_target_supports_mixed_zoned_model(type) (false) >> #endif >> >> +/* >> + * A target consumes inline crypto capabilities itself and doesn't support >> + * passing through inline crypto support. >> + */ >> +#define DM_TARGET_CONSUME_CRYPTO 0x00000300 >> +#define dm_target_consume_crypto(type) ((type)->features & >> DM_TARGET_CONSUME_CRYPTO) > > This patch doesn't make any sense. First, no new flag is needed, as the > behavior is already correct if you just leave DM_TARGET_PASSES_CRYPTO > unset, as far as I can tell. Second, the new flag is numerically equal > to DM_TARGET_PASSES_CRYPTO|CONFIG_BLK_DEV_ZONED. Third, even if it had > a unique bit as seems to have been intended, the behavior is the same as > DM_TARGET_PASSES_CRYPTO, which should not be used on this target. Thanks for your review! ACK. The key can be evicted through the real block device (the backend of DM device) during the removal of DM device when a blk-crypto-profile isn't tied to a DM device. I'll remove this patch in the next review. > > - Eric
