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.