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

[Christian Brauner <brauner@kernel.org>]

On Wed, May 17, 2023 at 02:02:59PM +0200, Christoph Hellwig wrote:
> On Wed, May 17, 2023 at 10:42:01AM +0200, Christian Brauner wrote:
> > 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.
> 
> Yes.  That's pretty much the definition of O_PATH..
> 
> > 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.
> 
> Why would we want to pin it?  That just means the device is open and
> you're have a non-O_PATH mount.

I think we're talking past each other. Both an O_PATH fd and a regular
fd would work. But its often desirable to pass a regular fd. If
userspace uses an O_PATH fd then the block device could be looked up
later during mounting via blkdev_open().

But when you use a regular fd blkdev_open() will be called and the
device resolved right at open time and we'll hold a reference to it.

So that way userspace can immediately know whether the device can be
opened/found. That's usually preferable. That's all I meant to say.

> 
> > 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.
> 
> What you seem to want is a way to convert an O_PATH fs into a non-O_PATH
> one.  Which seems generally useful, but isn't really anything block
> device specific.

That already exists, indirectly. You can reopen an O_PATH fd via
/proc/$pid/$nr. And Aleksa is working on O_EMPTYPATH to make this a
first class API including restrictions for how an O_PATH fd can be
reopened. We discussed that during LSFMM.