On Wed, Jun 04, 2025 at 12:13:38AM +0530, Anuj gupta wrote:
> > 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.
