[PATCH for-next v2 0/2] add ioctl to query protection info capabilities

[PATCH for-next v2 0/2] add ioctl to query protection info capabilities

[Anuj Gupta]

Hi all,

This patch series adds a new ioctl to query integrity capability.
Patch 1 adds a pi_size field in blk_integrity struct which is later
used to export this value to the user as well.
Patch 2 introduces a new ioctl to query integrity capability.

v1 -> v2
introduce metadata_size, storage_tag_size and ref_tag_size field in the
uapi struct (Martin)
uapi struct fields comment improvements (Martin)
add csum_type definitions to the uapi file (Martin)
add fpc_* prefix to uapi struct fields (Andreas)
bump the size of rsvd and hence the uapi struct to 32 bytes (Andreas)
use correct value for ioctl (Andreas)
use clearer names for CRC (Eric)

Anuj Gupta (2):
  block: introduce pi_size field in blk_integrity
  fs: add ioctl to query protection info capabilities

 block/blk-integrity.c         | 41 +++++++++++++++++++++++++++++++++++
 block/ioctl.c                 |  3 +++
 drivers/nvme/host/core.c      |  1 +
 drivers/scsi/sd_dif.c         |  1 +
 include/linux/blk-integrity.h |  6 +++++
 include/linux/blkdev.h        |  1 +
 include/uapi/linux/fs.h       | 38 ++++++++++++++++++++++++++++++++
 7 files changed, 91 insertions(+)

-- 
2.25.1

[PATCH for-next v2 1/2] block: introduce pi_size field in blk_integrity

[Anuj Gupta]

Introduce a new pi_size field in struct blk_integrity to explicitly
represent the size (in bytes) of the protection information (PI) tuple.
This is a prep patch.

Signed-off-by: Anuj Gupta <anuj20.g@samsung.com>
---
 drivers/nvme/host/core.c | 1 +
 drivers/scsi/sd_dif.c    | 1 +
 include/linux/blkdev.h   | 1 +
 3 files changed, 3 insertions(+)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index f69a232a000a..a9a2a0ca9797 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -1868,6 +1868,7 @@ static bool nvme_init_integrity(struct nvme_ns_head *head,
 	}
 
 	bi->tuple_size = head->ms;
+	bi->pi_size = head->pi_size;
 	bi->pi_offset = info->pi_offset;
 	return true;
 }
diff --git a/drivers/scsi/sd_dif.c b/drivers/scsi/sd_dif.c
index ae6ce6f5d622..9c39a82298da 100644
--- a/drivers/scsi/sd_dif.c
+++ b/drivers/scsi/sd_dif.c
@@ -53,6 +53,7 @@ void sd_dif_config_host(struct scsi_disk *sdkp, struct queue_limits *lim)
 		bi->flags |= BLK_INTEGRITY_REF_TAG;
 
 	bi->tuple_size = sizeof(struct t10_pi_tuple);
+	bi->pi_size = bi->tuple_size;
 
 	if (dif && type) {
 		bi->flags |= BLK_INTEGRITY_DEVICE_CAPABLE;
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 332b56f323d9..1ed604b70e0f 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -120,6 +120,7 @@ struct blk_integrity {
 	unsigned char				pi_offset;
 	unsigned char				interval_exp;
 	unsigned char				tag_size;
+	unsigned char				pi_size;
 };
 
 typedef unsigned int __bitwise blk_mode_t;
-- 
2.25.1

Re: [PATCH for-next v2 1/2] block: introduce pi_size field in blk_integrity

[Martin K. Petersen]

Anuj,

> Introduce a new pi_size field in struct blk_integrity to explicitly
> represent the size (in bytes) of the protection information (PI) tuple.
> This is a prep patch.

LGTM.

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

-- 
Martin K. Petersen

Re: [PATCH for-next v2 1/2] block: introduce pi_size field in blk_integrity

[Christoph Hellwig]

On Thu, Jun 05, 2025 at 08:37:28PM +0530, Anuj Gupta wrote:
> Introduce a new pi_size field in struct blk_integrity to explicitly
> represent the size (in bytes) of the protection information (PI) tuple.
> This is a prep patch.

These changes looks good, but I think we'll also want some validation
in blk-settings.c that the pi_size matches the chosen checksum.

[PATCH for-next v2 2/2] fs: add ioctl to query protection info capabilities

[Anuj Gupta]

Add a new ioctl, FS_IOC_GETPICAP, to query protection info (PI)
capabilities. This ioctl returns information about the files integrity
profile. This is useful for userspace applications to understand a files
end-to-end data protection support and configure the I/O accordingly.

For now this interface is only supported by block devices. However the
design and placement of this ioctl in generic FS ioctl space allows us
to extend it to work over files as well. This maybe useful when
filesystems start supporting  PI-aware layouts.

A new structure struct fs_pi_cap is introduced, which contains the
following fields:
1. fpc_flags: bitmask of capability flags.
2. fpc_interval: the data block interval (in bytes) for which the
protection information is generated.
3. fpc_csum type: type of checksum used.
4. fpc_metadata_size: size (in bytes) of the metadata associated with each
interval.
5. fpc_pi_size: size (in bytes) of the PI associated with each interval.
6. fpc_tag_size: size (in bytes) of tag information.
7. pi_offset: offset of protection information tuple within the
metadata.
8. fpc_ref_tag_size: size in bytes of the reference tag.
9. fpc_storage_tag_size: size in bytes of the storage tag.
10. fpc_rsvd: reserved for future use.

The internal logic to fetch the capability is encapsulated in a helper
function blk_get_pi_cap(), which uses the blk_integrity profile
associated with the device. The ioctl returns -EOPNOTSUPP, if
CONFIG_BLK_DEV_INTEGRITY is not enabled.

Signed-off-by: Anuj Gupta <anuj20.g@samsung.com>
Signed-off-by: Kanchan Joshi <joshi.k@samsung.com>
---
 block/blk-integrity.c         | 41 +++++++++++++++++++++++++++++++++++
 block/ioctl.c                 |  3 +++
 include/linux/blk-integrity.h |  6 +++++
 include/uapi/linux/fs.h       | 38 ++++++++++++++++++++++++++++++++
 4 files changed, 88 insertions(+)

diff --git a/block/blk-integrity.c b/block/blk-integrity.c
index e4e2567061f9..8f2c3a017328 100644
--- a/block/blk-integrity.c
+++ b/block/blk-integrity.c
@@ -13,6 +13,7 @@
 #include <linux/scatterlist.h>
 #include <linux/export.h>
 #include <linux/slab.h>
+#include <linux/t10-pi.h>
 
 #include "blk.h"
 
@@ -54,6 +55,46 @@ int blk_rq_count_integrity_sg(struct request_queue *q, struct bio *bio)
 	return segments;
 }
 
+int blk_get_pi_cap(struct block_device *bdev, struct fs_pi_cap __user *argp)
+{
+	struct blk_integrity *bi = blk_get_integrity(bdev->bd_disk);
+	struct fs_pi_cap pi_cap = {};
+
+	if (!bi)
+		goto out;
+
+	if (bi->flags & BLK_INTEGRITY_DEVICE_CAPABLE)
+		pi_cap.fpc_flags |= FILE_PI_CAP_INTEGRITY;
+	if (bi->flags & BLK_INTEGRITY_REF_TAG)
+		pi_cap.fpc_flags |= FILE_PI_CAP_REFTAG;
+	pi_cap.fpc_csum_type = bi->csum_type;
+	pi_cap.fpc_metadata_size = bi->tuple_size;
+	pi_cap.fpc_tag_size = bi->tag_size;
+	pi_cap.fpc_interval = 1 << bi->interval_exp;
+	pi_cap.fpc_pi_offset = bi->pi_offset;
+	pi_cap.fpc_pi_size = bi->pi_size;
+	if (bi->flags & BLK_INTEGRITY_REF_TAG) {
+		switch (bi->csum_type) {
+		case BLK_INTEGRITY_CSUM_CRC64:
+			pi_cap.fpc_ref_tag_size =
+				sizeof_field(struct crc64_pi_tuple, ref_tag);
+			break;
+		case BLK_INTEGRITY_CSUM_CRC:
+		case BLK_INTEGRITY_CSUM_IP:
+			pi_cap.fpc_ref_tag_size =
+				sizeof_field(struct t10_pi_tuple, ref_tag);
+			break;
+		default:
+			break;
+		}
+	}
+
+out:
+	if (copy_to_user(argp, &pi_cap, sizeof(struct fs_pi_cap)))
+		return -EFAULT;
+	return 0;
+}
+
 /**
  * blk_rq_map_integrity_sg - Map integrity metadata into a scatterlist
  * @rq:		request to map
diff --git a/block/ioctl.c b/block/ioctl.c
index e472cc1030c6..53b35bf3e6fa 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -13,6 +13,7 @@
 #include <linux/uaccess.h>
 #include <linux/pagemap.h>
 #include <linux/io_uring/cmd.h>
+#include <linux/blk-integrity.h>
 #include <uapi/linux/blkdev.h>
 #include "blk.h"
 #include "blk-crypto-internal.h"
@@ -643,6 +644,8 @@ static int blkdev_common_ioctl(struct block_device *bdev, blk_mode_t mode,
 		return blkdev_pr_preempt(bdev, mode, argp, true);
 	case IOC_PR_CLEAR:
 		return blkdev_pr_clear(bdev, mode, argp);
+	case FS_IOC_GETPICAP:
+		return blk_get_pi_cap(bdev, argp);
 	default:
 		return -ENOIOCTLCMD;
 	}
diff --git a/include/linux/blk-integrity.h b/include/linux/blk-integrity.h
index c7eae0bfb013..6118a0c28605 100644
--- a/include/linux/blk-integrity.h
+++ b/include/linux/blk-integrity.h
@@ -29,6 +29,7 @@ int blk_rq_map_integrity_sg(struct request *, struct scatterlist *);
 int blk_rq_count_integrity_sg(struct request_queue *, struct bio *);
 int blk_rq_integrity_map_user(struct request *rq, void __user *ubuf,
 			      ssize_t bytes);
+int blk_get_pi_cap(struct block_device *bdev, struct fs_pi_cap __user *argp);
 
 static inline bool
 blk_integrity_queue_supports_integrity(struct request_queue *q)
@@ -92,6 +93,11 @@ static inline struct bio_vec rq_integrity_vec(struct request *rq)
 				 rq->bio->bi_integrity->bip_iter);
 }
 #else /* CONFIG_BLK_DEV_INTEGRITY */
+static inline int blk_get_pi_cap(struct block_device *bdev,
+				 struct fs_pi_cap __user *argp)
+{
+	return -EOPNOTSUPP;
+}
 static inline int blk_rq_count_integrity_sg(struct request_queue *q,
 					    struct bio *b)
 {
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index 0098b0ce8ccb..5557a4598a38 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -91,6 +91,42 @@ struct fs_sysfs_path {
 	__u8			name[128];
 };
 
+/* Protection info capability flags */
+#define	FILE_PI_CAP_INTEGRITY		(1 << 0)
+#define	FILE_PI_CAP_REFTAG		(1 << 1)
+
+/* Checksum types for Protection Information */
+#define FS_PI_CSUM_NONE			0
+#define FS_PI_CSUM_IP			1
+#define FS_PI_CSUM_CRC16_T10DIF		2
+#define FS_PI_CSUM_CRC64_NVME		3
+
+/*
+ * struct fs_pi_cap - protection information(PI) capability descriptor
+ * @fpc_flags:			Bitmask of capability flags
+ * @fpc_interval:		Number of bytes of data per PI tuple
+ * @fpc_csum_type:		Checksum type
+ * @fpc_metadata_size:		Size in bytes of the metadata associated with each interval
+ * @fpc_pi_size:		Size in bytes of the PI associated with each interval
+ * @fpc_tag_size:		Size of the tag area within the tuple
+ * @fpc_pi_offset:		Offset of protection information tuple within the metadata
+ * @fpc_ref_tag_size:		Size in bytes of the reference tag
+ * @fpc_storage_tag_size:	Size in bytes of the storage tag
+ * @fpc_rsvd:			Reserved for future use
+ */
+struct fs_pi_cap {
+	__u32	fpc_flags;
+	__u16	fpc_interval;
+	__u8	fpc_csum_type;
+	__u8	fpc_metadata_size;
+	__u8	fpc_pi_size;
+	__u8	fpc_tag_size;
+	__u8	fpc_pi_offset;
+	__u8	fpc_ref_tag_size;
+	__u8	fpc_storage_tag_size;
+	__u8	fpc_rsvd[19];
+};
+
 /* extent-same (dedupe) ioctls; these MUST match the btrfs ioctl definitions */
 #define FILE_DEDUPE_RANGE_SAME		0
 #define FILE_DEDUPE_RANGE_DIFFERS	1
@@ -247,6 +283,8 @@ struct fsxattr {
  * also /sys/kernel/debug/ for filesystems with debugfs exports
  */
 #define FS_IOC_GETFSSYSFSPATH		_IOR(0x15, 1, struct fs_sysfs_path)
+/* Get protection info capability details */
+#define FS_IOC_GETPICAP			_IOR(0x15, 2, struct fs_pi_cap)
 
 /*
  * Inode flags (FS_IOC_GETFLAGS / FS_IOC_SETFLAGS)
-- 
2.25.1

Re: [PATCH for-next v2 2/2] fs: add ioctl to query protection info capabilities

[Martin K. Petersen]

Hi Anuj!

> A new structure struct fs_pi_cap is introduced, which contains the
> following fields:

Maybe fs_metadata_cap and then fmd_ as prefix in the struct?

> 2. fpc_interval: the data block interval (in bytes) for which the
> protection information is generated.

The data block interval (in bytes) associated with each unit of
metadata.

> 3. fpc_csum type: type of checksum used.

fmd_guard_tag_type

> 4. fpc_metadata_size: size (in bytes) of the metadata associated with each
> interval.

data block interval, perhaps?

> 6. fpc_tag_size: size (in bytes) of tag information.

fmd_app_tag_size: size (in bytes) of the application tag.

> 7. pi_offset: offset of protection information tuple within the
> metadata.

Yep.

> 8. fpc_ref_tag_size: size in bytes of the reference tag.
> 9. fpc_storage_tag_size: size in bytes of the storage tag.

Also good.

> +	case FS_IOC_GETPICAP:
> +		return blk_get_pi_cap(bdev, argp);

FS_IOC_METADATA_CAP?

> +/* Checksum types for Protection Information */
> +#define FS_PI_CSUM_NONE			0
> +#define FS_PI_CSUM_IP			1
> +#define FS_PI_CSUM_CRC16_T10DIF		2
> +#define FS_PI_CSUM_CRC64_NVME		3

I'll be adding CRC32 support soon. So maybe make CRC64 a "4" so it won't
look weird and unsorted in the uapi.

-- 
Martin K. Petersen

Re: [PATCH for-next v2 2/2] fs: add ioctl to query protection info capabilities

[Anuj gupta]

On Fri, Jun 6, 2025 at 7:37 AM Martin K. Petersen
<martin.petersen@oracle.com> wrote:
>
>
> Hi Anuj!
>
> > A new structure struct fs_pi_cap is introduced, which contains the
> > following fields:
>
> Maybe fs_metadata_cap and then fmd_ as prefix in the struct?
>
>
> > +     case FS_IOC_GETPICAP:
> > +             return blk_get_pi_cap(bdev, argp);
>
> FS_IOC_METADATA_CAP?
>

Hi Martin,

Thanks for the suggestion. I see your point — especially from the NVMe
perspective, where integrity buffer can be larger than just the PI
tuple.

However, since this ioctl is also intended to work on regular files,
where "metadata" usually refers to inode-level attributes, timestamps,
permissions, etc., I worry that FS_IOC_METADATA_CAP and fs_metadata_cap
might be confusing in the broader filesystem context.

Using  FS_IOC_GETPI_CAP and struct fs_pi_cap seems more narrowly scoped
and avoids that ambiguity. Do you see this differently? Or if you have a
better alternative in mind, I’d be happy to consider it.

Thanks,
Anuj Gupta

Re: [PATCH for-next v2 2/2] fs: add ioctl to query protection info capabilities

[Martin K. Petersen]

Hi Anuj!

> Thanks for the suggestion. I see your point — especially from the NVMe
> perspective, where integrity buffer can be larger than just the PI
> tuple.
>
> However, since this ioctl is also intended to work on regular files,
> where "metadata" usually refers to inode-level attributes, timestamps,
> permissions, etc., I worry that FS_IOC_METADATA_CAP and
> fs_metadata_cap might be confusing in the broader filesystem context.
>
> Using FS_IOC_GETPI_CAP and struct fs_pi_cap seems more narrowly scoped
> and avoids that ambiguity. Do you see this differently? Or if you have
> a better alternative in mind, I’d be happy to consider it.

I agree it's ambiguous. I just find it equally confusing that "PI" is
now being used to describe opaque metadata which has nothing to do with
PI.

When the block layer code was originally implemented I tried to be
careful about using the term "integrity metadata" everywhere to
distinguish it from "filesystem metadata". It was deliberate not to use
T10 terms in the block layer since there were other competing protection
formats at the time. So one way to get us out of this naming problem
would be to clearly distinguish between for instance "logical block
metadata" and "filesystem metadata".

An alternative would be to revive the concept of "block tagging". The
reason the existing "tag_size" parameter is not called "app_tag_size" is
that the "tag" is "filesystem tag". The fact that it was backed by the
application tag in the PI case was coincidental. The idea at the time
was that filesystems would tag their filesystem blocks with backpointers
and additional information about the contents which would be useful in a
recovery scenario (i.e. "this is a data block for inode XYZ"). So we
could entertain "block tag".

Anyway. I'm thinking something along the lines of this:

* struct logical_block_metadata_cap - Logical block metadata
* @lbmd_flags:			Bitmask of logical block metadata capability flags
* @lbmd_interval:		The amount of data described by each unit of logical block metadata
* @lbmd_size:			Size in bytes of the logical block metadata associated with each interval
* @lbmd_opaque_size:		Size in bytes of the opaque block tag associated with each interval
* @lbmd_opaque_offset:		Offset in bytes of the opaque block tag within the logical block metadata
* @lbmd_pi_size:		Size in bytes of the T10 PI tuple associated with each interval
* @lbmd_pi_offset:		Offset in bytes of T10 PI tuple within the logical block metadata
* @lbmd_pi_guard_tag_type:	T10 PI guard tag type
* @lbmd_pi_app_tag_size:	Size in bytes of the T10 PI application tag
* @lbmd_pi_ref_tag_size:	Size in bytes of the T10 PI reference tag
* @lbmd_pi_storage_tag_size:	Size in bytes of the T10 PI storage tag
* @lbmd_rsvd:			Reserved for future use

That way there's a clear distinction between "all of the metadata", "the
non-PI metadata", and "the PI metadata". Also saves the caller from
doing size and offset calculations by hand for the non-PI stuff.

-- 
Martin K. Petersen

Re: [PATCH for-next v2 2/2] fs: add ioctl to query protection info capabilities

[Christoph Hellwig]

On Thu, Jun 05, 2025 at 10:07:00PM -0400, Martin K. Petersen wrote:
> 
> Hi Anuj!
> 
> > A new structure struct fs_pi_cap is introduced, which contains the
> > following fields:
> 
> Maybe fs_metadata_cap and then fmd_ as prefix in the struct?

Yeah, that does sound better.

Re: [PATCH for-next v2 2/2] fs: add ioctl to query protection info capabilities

[Anuj Gupta/Anuj Gupta]

On 6/9/2025 9:41 AM, Christoph Hellwig wrote:
> On Thu, Jun 05, 2025 at 10:07:00PM -0400, Martin K. Petersen wrote:
>>
>> Hi Anuj!
>>
>>> A new structure struct fs_pi_cap is introduced, which contains the
>>> following fields:
>>
>> Maybe fs_metadata_cap and then fmd_ as prefix in the struct?
> 
> Yeah, that does sound better.
> 
> 
Based on the recent discussion and suggestion from Martin [1] I was
planning to use logical_block_metadata_cap instead. Does that idea sound
fine to you?

[1] 
https://lore.kernel.org/linux-block/20250605150729.2730-1-anuj20.g@samsung.com/

Re: [PATCH for-next v2 2/2] fs: add ioctl to query protection info capabilities

[Christoph Hellwig]

On Mon, Jun 09, 2025 at 11:14:42AM +0530, Anuj Gupta/Anuj Gupta wrote:
> On 6/9/2025 9:41 AM, Christoph Hellwig wrote:
> > On Thu, Jun 05, 2025 at 10:07:00PM -0400, Martin K. Petersen wrote:
> >>
> >> Hi Anuj!
> >>
> >>> A new structure struct fs_pi_cap is introduced, which contains the
> >>> following fields:
> >>
> >> Maybe fs_metadata_cap and then fmd_ as prefix in the struct?
> > 
> > Yeah, that does sound better.
> > 
> > 
> Based on the recent discussion and suggestion from Martin [1] I was
> planning to use logical_block_metadata_cap instead. Does that idea sound
> fine to you?

It's okay.  I find the name a little long, but at least it describes
what is going on.

Re: [PATCH for-next v2 2/2] fs: add ioctl to query protection info capabilities

[Martin K. Petersen]

Christoph,

>> Based on the recent discussion and suggestion from Martin [1] I was
>> planning to use logical_block_metadata_cap instead. Does that idea sound
>> fine to you?
>
> It's okay.  I find the name a little long, but at least it describes
> what is going on.

We could drop the _cap.

-- 
Martin K. Petersen