Re: [PATCH v2 2/3] fs: introduce f_real_path() helper

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

 



On Mon, Jun 12, 2023 at 9:36 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
>
> On Mon, Jun 12, 2023 at 09:28:40AM +0300, Amir Goldstein wrote:
> > On Mon, Jun 12, 2023 at 7:36 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> > >
> > > On Sun, Jun 11, 2023 at 04:27:31PM +0300, Amir Goldstein wrote:
> > > > Overlayfs knows the real path of underlying dentries.  Add an optional
> > > > struct vfsmount out argument to ->d_real(), so callers could compose the
> > > > real path.
> > > >
> > > > Add a helper f_real_path() that uses this new interface to return the
> > > > real path of f_inode, for overlayfs internal files whose f_path if a
> > > > "fake" overlayfs path and f_inode is the underlying real inode.
> > >
> > > I really don't like this ->d_real nagic.  Most callers of it
> > > really can't ever be on overlayfs.
> >
> > Which callers are you referring to?
>
> Most users of file_dentry are inside file systems and will never
> see the overlayfs path.
>

Ay ay ay.
I suspected that this is what you meant and I do not blame you.
There is no documentation and it is hard to understand what is going on
even harder to understand why that is going on...

Before "ovl: stack file ops" series, a file opened from ovl (over xfs) path
would have ovl f_path and xfs f_inode, as well as xfs f_ops, so indeed xfs
code had to be careful, but so did a lot of generic vfs code.

After ovl stacked f_ops, a file opened from ovl (over xfs) path has an
ovl f_path and an ovl f_inode, so a lot of hacks could be removed from
generic vfs code (e.g. locks_inode() macro).

Alas, for every ovl file, there is an "internal/real" file (stashed in
file->f_private)
which is opened by open_with_fake_path().
This "internal/real" file has ovl f_path and xfs f_inode, so xfs could
not get rid
of file_dentry() just yet.

Currently, the reason for the fake f_path hack is that the same internal file
is assigned as ->vm_file in ovl_mmap(), ovl does not implement stacked aops
and some users of ->vm_file need the "fake" ovl path.

Anyway, the first step is to introduce the ovl internal file container.
Next, we will use the real_path for file_dentry() and we can see if we
can get rid of some of these file_dentry() uses.

Thanks,
Amir.




[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux