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.
