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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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'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.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux