On Wed, Jun 04, 2025 at 12:13:38AM +0530, Anuj gupta wrote:

quoted

Hm, I wonder whether we should just make all of this an extension of the
new file_getattr() system call we're about to add instead of adding a
separate ioctl for this.

Hi Christian,
Thanks for the suggestion to explore file_getattr() for exposing PI
capabilities. I spent some time evaluating this path.

Block devices don’t implement inode_operations, including fileattr_get,
so invoking file_getattr() on something like /dev/nvme0n1 currently
returns -EOPNOTSUPP.  Supporting this would require introducing
inode_operations, and then wiring up fileattr_get in the block layer.

Given that, I think sticking with an ioctl may be the cleaner approach.
Do you see this differently?

Would it be so bad to add custom inode operations?
It's literally just something like:

diff --git a/block/bdev.c b/block/bdev.c
index b77ddd12dc06..9b4f76e2afca 100644
--- a/block/bdev.c
+++ b/block/bdev.c

@@ -453,6 +453,11 @@ void __init bdev_cache_init(void)
        blockdev_superblock = blockdev_mnt->mnt_sb;   /* For writeback */
 }

+static const struct inode_operations bdev_inode_operations = {
+       .fileattr_get   = bdev_file_attr_get,
+       .fileattr_set   = bdev_file_attr_set,
+}
+
 struct block_device *bdev_alloc(struct gendisk *disk, u8 partno)
 {
        struct block_device *bdev;

@@ -462,6 +467,7 @@ struct block_device *bdev_alloc(struct gendisk *disk, u8 partno)
        if (!inode)
                return NULL;
        inode->i_mode = S_IFBLK;
+       inode->i_op = &bdev_inode_operations;
        inode->i_rdev = 0;
        inode->i_data.a_ops = &def_blk_aops;
        mapping_set_gfp_mask(&inode->i_data, GFP_USER);

instead of using empty_iops.