| Message ID | 20250225044653.6867-2-anuj20.g@samsung.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v1,1/3] block: Fix incorrect integrity sysfs reporting for DM devices | expand |
On Tue, Feb 25, 2025 at 10:16:51AM +0530, Anuj Gupta wrote: > The integrity stacking logic in device-mapper currently does not > explicitly mark the device with BLK_INTEGRITY_NOGENERATE and > BLK_INTEGRITY_NOVERIFY when the underlying device(s) do not support > integrity. This can lead to incorrect sysfs reporting of integrity > attributes. > > Additionally, queue_limits_stack_integrity() incorrectly sets > BLK_INTEGRITY_DEVICE_CAPABLE for a DM device even when none of its > underlying devices support integrity. This happens because the flag is > blindly inherited from the first base device, even if it lacks integrity > support. > > This patch ensures: > 1. BLK_INTEGRITY_NOGENERATE and BLK_INTEGRITY_NOVERIFY are set correctly: > - When the underlying device does not support integrity. > - When integrity stacking fails due to incompatible profiles. > 2. device_is_integrity_capable is correctly propagated to reflect the > actual capability of the stacked device. > > Reported-by: M Nikhil <nikhilm@linux.ibm.com> > Link: https://lore.kernel.org/linux-block/f6130475-3ccd-45d2-abde-3ccceada0f0a@linux.ibm.com/ > Fixes: c6e56cf6b2e7 ("block: move integrity information into queue_limits") > Signed-off-by: Anuj Gupta <anuj20.g@samsung.com> > --- > block/blk-settings.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/block/blk-settings.c b/block/blk-settings.c > index c44dadc35e1e..c32517c8bc2e 100644 > --- a/block/blk-settings.c > +++ b/block/blk-settings.c > @@ -861,7 +861,8 @@ bool queue_limits_stack_integrity(struct queue_limits *t, > > if (!ti->tuple_size) { > /* inherit the settings from the first underlying device */ > - if (!(ti->flags & BLK_INTEGRITY_STACKED)) { > + if (!(ti->flags & BLK_INTEGRITY_STACKED) && > + (bi->flags & BLK_INTEGRITY_DEVICE_CAPABLE)) { > ti->flags = BLK_INTEGRITY_DEVICE_CAPABLE | > (bi->flags & BLK_INTEGRITY_REF_TAG); > ti->csum_type = bi->csum_type; Hmm. I wonder if this is the correct logic. Basically we do not want to allow mixing integrity capable and not integrity devices, do we? So maybe the logic should be more something like: if (!IS_ENABLED(CONFIG_BLK_DEV_INTEGRITY)) return true; if (ti->flags & BLK_INTEGRITY_STACKED) { /* check blk_integrity compatibility */ } else { ti->flags = BLK_INTEGRITY_STACKED; /* inherit blk_integrity, including the empty one */ }
> > diff --git a/block/blk-settings.c b/block/blk-settings.c > > index c44dadc35e1e..c32517c8bc2e 100644 > > --- a/block/blk-settings.c > > +++ b/block/blk-settings.c > > @@ -861,7 +861,8 @@ bool queue_limits_stack_integrity(struct queue_limits *t, > > > > if (!ti->tuple_size) { > > /* inherit the settings from the first underlying device */ > > - if (!(ti->flags & BLK_INTEGRITY_STACKED)) { > > + if (!(ti->flags & BLK_INTEGRITY_STACKED) && > > + (bi->flags & BLK_INTEGRITY_DEVICE_CAPABLE)) { > > ti->flags = BLK_INTEGRITY_DEVICE_CAPABLE | > > (bi->flags & BLK_INTEGRITY_REF_TAG); > > ti->csum_type = bi->csum_type; > > Hmm. I wonder if this is the correct logic. Basically we do not want to > allow mixing integrity capable and not integrity devices, do we? It is about a situation where a non-integrity-capable device incorrectly reports integrity capability due to improper flag propagation. The issue is that BLK_INTEGRITY_DEVICE_CAPABLE is set incorrectly even when the first underlying device does not support integrity. This part of the patch tries to fix that. For example, when I create a dm-linear device using an integrity-incapable device, the resulting DM device wrongly reports integrity capability [1] Rest of the handling in this patch would not be required once we correctly initialize in blk_validate_integrity_limits as you suggested in the other reply [2] [1] # cat /sys/block/nvme0n1/integrity/device_is_integrity_capable 0 # echo 0 409600 linear /dev/nvme0n1 0 > /tmp/table # echo 409600 409600 linear /dev/nvme0n1 0 >> /tmp/table # dmsetup create two /tmp/table # cat /sys/block/dm-0/integrity/device_is_integrity_capable 1 [2] https://lore.kernel.org/linux-block/20250225150753.GB6099@lst.de/ > So maybe the logic should be more something like: > > if (!IS_ENABLED(CONFIG_BLK_DEV_INTEGRITY)) > return true; > > if (ti->flags & BLK_INTEGRITY_STACKED) { > /* check blk_integrity compatibility */ > } else { > ti->flags = BLK_INTEGRITY_STACKED; > /* inherit blk_integrity, including the empty one */ > } >
diff --git a/block/blk-settings.c b/block/blk-settings.c index c44dadc35e1e..c32517c8bc2e 100644 --- a/block/blk-settings.c +++ b/block/blk-settings.c @@ -861,7 +861,8 @@ bool queue_limits_stack_integrity(struct queue_limits *t, if (!ti->tuple_size) { /* inherit the settings from the first underlying device */ - if (!(ti->flags & BLK_INTEGRITY_STACKED)) { + if (!(ti->flags & BLK_INTEGRITY_STACKED) && + (bi->flags & BLK_INTEGRITY_DEVICE_CAPABLE)) { ti->flags = BLK_INTEGRITY_DEVICE_CAPABLE | (bi->flags & BLK_INTEGRITY_REF_TAG); ti->csum_type = bi->csum_type; @@ -871,8 +872,11 @@ bool queue_limits_stack_integrity(struct queue_limits *t, ti->tag_size = bi->tag_size; goto done; } - if (!bi->tuple_size) + if (!bi->tuple_size) { + ti->flags |= BLK_INTEGRITY_NOGENERATE | + BLK_INTEGRITY_NOVERIFY; goto done; + } } if (ti->tuple_size != bi->tuple_size) @@ -893,6 +897,7 @@ bool queue_limits_stack_integrity(struct queue_limits *t, incompatible: memset(ti, 0, sizeof(*ti)); + ti->flags |= BLK_INTEGRITY_NOGENERATE | BLK_INTEGRITY_NOVERIFY; return false; } EXPORT_SYMBOL_GPL(queue_limits_stack_integrity);
The integrity stacking logic in device-mapper currently does not explicitly mark the device with BLK_INTEGRITY_NOGENERATE and BLK_INTEGRITY_NOVERIFY when the underlying device(s) do not support integrity. This can lead to incorrect sysfs reporting of integrity attributes. Additionally, queue_limits_stack_integrity() incorrectly sets BLK_INTEGRITY_DEVICE_CAPABLE for a DM device even when none of its underlying devices support integrity. This happens because the flag is blindly inherited from the first base device, even if it lacks integrity support. This patch ensures: 1. BLK_INTEGRITY_NOGENERATE and BLK_INTEGRITY_NOVERIFY are set correctly: - When the underlying device does not support integrity. - When integrity stacking fails due to incompatible profiles. 2. device_is_integrity_capable is correctly propagated to reflect the actual capability of the stacked device. Reported-by: M Nikhil <nikhilm@linux.ibm.com> Link: https://lore.kernel.org/linux-block/f6130475-3ccd-45d2-abde-3ccceada0f0a@linux.ibm.com/ Fixes: c6e56cf6b2e7 ("block: move integrity information into queue_limits") Signed-off-by: Anuj Gupta <anuj20.g@samsung.com> --- block/blk-settings.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)