> > 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@xxxxxx/
> 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 */
> }
>
