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 04:26:09PM +0200, Christoph Hellwig wrote:
> On Wed, May 17, 2023 at 03:14:40PM +0200, Christian Brauner wrote:
> > > 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 know what you mean.  But based on the concept of how O_PATH and
> block devices work it really doesn't make any sense to have a block
> device handle for an O_PATH fd, except for the actual fd itself.

Fwiw, I didn't mean to have a special device handler for an O_PATH fd.
I really just tried to figure out whether it would make sense to have an
fd-based block device lookup function because right now we only have
blkdev_get_by_path() and we'd be passing blkdev fds through the mount
api. But I understand now how I'd likely do it. So now just finding time
to actually implement it.



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux