Re: [PATCH 5/9] block: introduce holder ops

[Christian Brauner <brauner@kernel.org>]

On Wed, May 17, 2023 at 10:06:13AM +0200, Christoph Hellwig wrote:
> On Wed, May 17, 2023 at 09:57:55AM +0200, Christian Brauner wrote:
> > BTW, why is there no code to lookup a bdev by O_PATH fd? It seems weird
> > that a lot of ioctls pass the device path to the kernel (btrfs comes to
> > mind). I can see certain things that would make this potentially a bit
> > tricky e.g., you'd not have access to the path/name of the device if you
> > want to show it somewhere such as in mountinfo but nothing that makes it
> > impossible afaict.
> 
> As far as I can tell you should be able to hold a reference to a block
> device file descriptor with an O_PATH fd.   Or did I miss something
> that specifically prohibits that?

So with an O_PATH fd the device wouldn't really be opened at all we'd
just hold a reference to a struct file with f->f_op set to empty_fops.
(See the FMODE_PATH code in fs/open.c:do_dentry_open().)

So blkdev_open() is never called for O_PATH fds. Consequently an O_PATH
fd to a block device would only be useful if the intention is to later
lookup the block device based on inode->i_rdev.

So my earlier question should have been why there's no method to lookup
a block device purely by non-O_PATH fd since that way you do actually
pin the block device which is probably what you almost always want to do.

I'm asking because it would be nice if we could allow callers to specify
the source of a filesystem mount as an fd and not just as a string as
the mount api currently does. That's probably not super straightforward
but might be really worth it.