Re: [PATCH v1 1/3] block: Fix incorrect integrity sysfs reporting for DM devices

[Christoph Hellwig <hch@xxxxxx>]

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@xxxxxxxxxxxxx>
> Link: https://lore.kernel.org/linux-block/f6130475-3ccd-45d2-abde-3ccceada0f0a@xxxxxxxxxxxxx/
> Fixes: c6e56cf6b2e7 ("block: move integrity information into queue_limits")
> Signed-off-by: Anuj Gupta <anuj20.g@xxxxxxxxxxx>
> ---
>  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  */
	}