[PATCH v2] block: fix lbmd_guard_tag_type assignment in FS_IOC_GETLBMD_CAP

[PATCH v2] block: fix lbmd_guard_tag_type assignment in FS_IOC_GETLBMD_CAP

[Anuj Gupta]

The blk_get_meta_cap() implementation directly assigns bi->csum_type to
the UAPI field lbmd_guard_tag_type. This is not right as the kernel enum
blk_integrity_checksum values are not guaranteed to match the UAPI
defined values.

Fix this by explicitly mapping internal checksum types to UAPI-defined
constants to ensure compatibility and correctness, especially for the
devices using CRC64 PI.

Fixes: 9eb22f7fedfc ("fs: add ioctl to query metadata and protection info capabilities")
Reported-by: Vincent Fu <vincent.fu@samsung.com>
Signed-off-by: Anuj Gupta <anuj20.g@samsung.com>
---
 block/blk-integrity.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/block/blk-integrity.c b/block/blk-integrity.c
index 61a79e19c78f..056b8948369d 100644
--- a/block/blk-integrity.c
+++ b/block/blk-integrity.c
@@ -83,7 +83,21 @@ int blk_get_meta_cap(struct block_device *bdev, unsigned int cmd,
 	if (meta_cap.lbmd_opaque_size && !bi->pi_offset)
 		meta_cap.lbmd_opaque_offset = bi->pi_tuple_size;
 
-	meta_cap.lbmd_guard_tag_type = bi->csum_type;
+	switch (bi->csum_type) {
+	case BLK_INTEGRITY_CSUM_NONE:
+		meta_cap.lbmd_guard_tag_type = LBMD_PI_CSUM_NONE;
+		break;
+	case BLK_INTEGRITY_CSUM_IP:
+		meta_cap.lbmd_guard_tag_type = LBMD_PI_CSUM_IP;
+		break;
+	case BLK_INTEGRITY_CSUM_CRC:
+		meta_cap.lbmd_guard_tag_type = LBMD_PI_CSUM_CRC16_T10DIF;
+		break;
+	case BLK_INTEGRITY_CSUM_CRC64:
+		meta_cap.lbmd_guard_tag_type = LBMD_PI_CSUM_CRC64_NVME;
+		break;
+	}
+
 	if (bi->csum_type != BLK_INTEGRITY_CSUM_NONE)
 		meta_cap.lbmd_app_tag_size = 2;
 
-- 
2.25.1

Re: [PATCH v2] block: fix lbmd_guard_tag_type assignment in FS_IOC_GETLBMD_CAP

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH v2] block: fix lbmd_guard_tag_type assignment in FS_IOC_GETLBMD_CAP

[Jens Axboe]

On 7/22/25 3:13 AM, Anuj Gupta wrote:
> The blk_get_meta_cap() implementation directly assigns bi->csum_type to
> the UAPI field lbmd_guard_tag_type. This is not right as the kernel enum
> blk_integrity_checksum values are not guaranteed to match the UAPI
> defined values.
> 
> Fix this by explicitly mapping internal checksum types to UAPI-defined
> constants to ensure compatibility and correctness, especially for the
> devices using CRC64 PI.
> 
> Fixes: 9eb22f7fedfc ("fs: add ioctl to query metadata and protection info capabilities")

Where is this sha? It's not in the block or upstream tree, presumably
it's in the vfs tree due to it being an fs commit? In which case
you should probably CC that side, as this cannot be picked up on
the block side.

-- 
Jens Axboe

Re: [PATCH v2] block: fix lbmd_guard_tag_type assignment in FS_IOC_GETLBMD_CAP

[Martin K. Petersen]

Anuj,

> The blk_get_meta_cap() implementation directly assigns bi->csum_type to
> the UAPI field lbmd_guard_tag_type. This is not right as the kernel enum
> blk_integrity_checksum values are not guaranteed to match the UAPI
> defined values.
>
> Fix this by explicitly mapping internal checksum types to UAPI-defined
> constants to ensure compatibility and correctness, especially for the
> devices using CRC64 PI.

Looks fine.

Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>

-- 
Martin K. Petersen

Re: [PATCH v2] block: fix lbmd_guard_tag_type assignment in FS_IOC_GETLBMD_CAP

[Anuj gupta]

>
> Where is this sha? It's not in the block or upstream tree, presumably
> it's in the vfs tree due to it being an fs commit? In which case
> you should probably CC that side, as this cannot be picked up on
> the block side.
>
Thanks Jens, you're right — the original patch went through the VFS
tree. I'll resend the patch and CC Christian and fsdevel accordingly so
that it can be routed through the correct tree.

Thanks,
Anuj Gupta
> --
> Jens Axboe
>

Re: [PATCH v2] block: fix lbmd_guard_tag_type assignment in FS_IOC_GETLBMD_CAP

[Jens Axboe]

On 7/22/25 5:57 AM, Anuj gupta wrote:
>>
>> Where is this sha? It's not in the block or upstream tree, presumably
>> it's in the vfs tree due to it being an fs commit? In which case
>> you should probably CC that side, as this cannot be picked up on
>> the block side.
>>
> Thanks Jens, you're right ? the original patch went through the VFS
> tree. I'll resend the patch and CC Christian and fsdevel accordingly so
> that it can be routed through the correct tree.

Sounds good, otherwise I don't think it's going anywhere. You can add

Reviewed-by: Jens Axboe <axboe@kernel.dk>

as well.

-- 
Jens Axboe