| Message ID | 20231009153712.1566422-4-amir73il@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Reduce impact of overlayfs backing files fake path | expand |
On Mon, 9 Oct 2023 at 17:37, Amir Goldstein <amir73il@gmail.com> wrote: > static inline void put_file_access(struct file *file) > diff --git a/fs/open.c b/fs/open.c > index fe63e236da22..02dc608d40d8 100644 > --- a/fs/open.c > +++ b/fs/open.c > @@ -881,7 +881,7 @@ static inline int file_get_write_access(struct file *f) > if (unlikely(error)) > goto cleanup_inode; > if (unlikely(f->f_mode & FMODE_BACKING)) { > - error = mnt_get_write_access(backing_file_real_path(f)->mnt); > + error = mnt_get_write_access(backing_file_user_path(f)->mnt); > if (unlikely(error)) > goto cleanup_mnt; > } Do we really need write access on the overlay mount? If so, should the order of getting write access not be the other way round (overlay first, backing second)? Thanks, Miklos
On Tue, Oct 10, 2023 at 2:59 PM Miklos Szeredi <miklos@szeredi.hu> wrote: > > On Mon, 9 Oct 2023 at 17:37, Amir Goldstein <amir73il@gmail.com> wrote: > > > static inline void put_file_access(struct file *file) > > diff --git a/fs/open.c b/fs/open.c > > index fe63e236da22..02dc608d40d8 100644 > > --- a/fs/open.c > > +++ b/fs/open.c > > @@ -881,7 +881,7 @@ static inline int file_get_write_access(struct file *f) > > if (unlikely(error)) > > goto cleanup_inode; > > if (unlikely(f->f_mode & FMODE_BACKING)) { > > - error = mnt_get_write_access(backing_file_real_path(f)->mnt); > > + error = mnt_get_write_access(backing_file_user_path(f)->mnt); > > if (unlikely(error)) > > goto cleanup_mnt; > > } > > Do we really need write access on the overlay mount? > I'd rather this vfs code be generic and not assume things about ovl private mount. These assumptions may not hold for fuse passthough backing files. That said, if we have an open(O_RDWR),mmap(PROT_WRITE),close() sequence on overlayfs, don't we need the write access on ovl_upper_mnt in order to avoid upper sb from being remounted RO? > If so, should the order of getting write access not be the other way > round (overlay first, backing second)? > Why is the order important? What am I missing? Thanks, Amir.
On Tue, Oct 10, 2023 at 4:10 PM Amir Goldstein <amir73il@gmail.com> wrote: > > On Tue, Oct 10, 2023 at 2:59 PM Miklos Szeredi <miklos@szeredi.hu> wrote: > > > > On Mon, 9 Oct 2023 at 17:37, Amir Goldstein <amir73il@gmail.com> wrote: > > > > > static inline void put_file_access(struct file *file) > > > diff --git a/fs/open.c b/fs/open.c > > > index fe63e236da22..02dc608d40d8 100644 > > > --- a/fs/open.c > > > +++ b/fs/open.c > > > @@ -881,7 +881,7 @@ static inline int file_get_write_access(struct file *f) > > > if (unlikely(error)) > > > goto cleanup_inode; > > > if (unlikely(f->f_mode & FMODE_BACKING)) { > > > - error = mnt_get_write_access(backing_file_real_path(f)->mnt); > > > + error = mnt_get_write_access(backing_file_user_path(f)->mnt); > > > if (unlikely(error)) > > > goto cleanup_mnt; > > > } > > > > Do we really need write access on the overlay mount? > > > > I'd rather this vfs code be generic and not assume things about > ovl private mount. > These assumptions may not hold for fuse passthough backing files. > > That said, if we have an open(O_RDWR),mmap(PROT_WRITE),close() > sequence on overlayfs, don't we need the write access on ovl_upper_mnt > in order to avoid upper sb from being remounted RO? > Sorry, you asked about ovl mount. To me it makes sense that if users observe ovl paths in writable mapped memory, that ovl should not be remounted RO. Anyway, I don't see a good reason to allow remount RO for ovl in that case. Is there? > > If so, should the order of getting write access not be the other way > > round (overlay first, backing second)? > > > > Why is the order important? > What am I missing? > > Thanks, > Amir.
On Tue, 10 Oct 2023 at 15:17, Amir Goldstein <amir73il@gmail.com> wrote: > Sorry, you asked about ovl mount. > To me it makes sense that if users observe ovl paths in writable mapped > memory, that ovl should not be remounted RO. > Anyway, I don't see a good reason to allow remount RO for ovl in that case. > Is there? Agreed. But is preventing remount RO important enough to warrant special casing of backing file in generic code? I'm not convinced either way... Thanks, Miklos
On Tue, Oct 10, 2023 at 4:34 PM Miklos Szeredi <miklos@szeredi.hu> wrote: > > On Tue, 10 Oct 2023 at 15:17, Amir Goldstein <amir73il@gmail.com> wrote: > > > Sorry, you asked about ovl mount. > > To me it makes sense that if users observe ovl paths in writable mapped > > memory, that ovl should not be remounted RO. > > Anyway, I don't see a good reason to allow remount RO for ovl in that case. > > Is there? > > Agreed. > > But is preventing remount RO important enough to warrant special > casing of backing file in generic code? I'm not convinced either > way... I prefer correctness and I doubt that the check if (unlikely(f->f_mode & FMODE_BACKING)) is worth optimizing. but I will let Christian make the final call. Thanks, Amir.
On Tue, Oct 10, 2023 at 03:34:45PM +0200, Miklos Szeredi wrote: > On Tue, 10 Oct 2023 at 15:17, Amir Goldstein <amir73il@gmail.com> wrote: > > > Sorry, you asked about ovl mount. > > To me it makes sense that if users observe ovl paths in writable mapped > > memory, that ovl should not be remounted RO. > > Anyway, I don't see a good reason to allow remount RO for ovl in that case. > > Is there? > > Agreed. > > But is preventing remount RO important enough to warrant special > casing of backing file in generic code? I'm not convinced either > way... You definitely want to guarantee that remounting filesystem r/o prevents the changes of visible contents; it's not just POSIX, it's a fairly basic common assumption about any local filesystems. Whether that should affect generic code... You could do what CODA does, I suppose; call ->mmap() of underlying file, then copy the resulting ->vm_ops into your private structure and override ->close() there (keeping the original elsewhere in the same structure). Then your ->close() would call the original and drop write access on the ovl mount explicitly taken in your ->open(). *IF* we go that way, we probably ought to provide a ->get_path() method for VMAs (NULL meaning "take ->vm_file->f_path") and use that in procfs accesses. That could reduce the impact on generic code pretty much to zero - FMODE_BACKING included. But it would cost you an allocation of vm_operations_struct per mmap, most of them almost identical ;-/ And merging would not be trivial - CODA stores a reference to original ->vm_file in that structure, and uses container_of() to get to it in their ->close(). AFAICS, there's no other safe place to stash that information in anywhere in vm_area_struct.
On Tue, Oct 10, 2023 at 05:55:04PM +0100, Al Viro wrote: > On Tue, Oct 10, 2023 at 03:34:45PM +0200, Miklos Szeredi wrote: > > On Tue, 10 Oct 2023 at 15:17, Amir Goldstein <amir73il@gmail.com> wrote: > > > > > Sorry, you asked about ovl mount. > > > To me it makes sense that if users observe ovl paths in writable mapped > > > memory, that ovl should not be remounted RO. > > > Anyway, I don't see a good reason to allow remount RO for ovl in that case. > > > Is there? > > > > Agreed. > > > > But is preventing remount RO important enough to warrant special > > casing of backing file in generic code? I'm not convinced either > > way... > > You definitely want to guarantee that remounting filesystem r/o > prevents the changes of visible contents; it's not just POSIX, > it's a fairly basic common assumption about any local filesystems. Incidentally, could we simply keep a reference to original struct file instead of messing with path? The only caller of backing_file_open() gets &file->f_path as user_path; how about passing file instead, and having backing_file_open() do get_file() on it and stash the sucker into your object? And have put_file_access() do if (unlikely(file->f_mode & FMODE_BACKING)) fput(backing_file(file)->file); in the end. No need to mess with write access in any special way and it's closer to the semantics we have for normal mmap(), after all - it keeps the file we'd passed to it open as long as mapping is there. Comments?
On Tue, Oct 10, 2023 at 8:41 PM Al Viro <viro@zeniv.linux.org.uk> wrote: > > On Tue, Oct 10, 2023 at 05:55:04PM +0100, Al Viro wrote: > > On Tue, Oct 10, 2023 at 03:34:45PM +0200, Miklos Szeredi wrote: > > > On Tue, 10 Oct 2023 at 15:17, Amir Goldstein <amir73il@gmail.com> wrote: > > > > > > > Sorry, you asked about ovl mount. > > > > To me it makes sense that if users observe ovl paths in writable mapped > > > > memory, that ovl should not be remounted RO. > > > > Anyway, I don't see a good reason to allow remount RO for ovl in that case. > > > > Is there? > > > > > > Agreed. > > > > > > But is preventing remount RO important enough to warrant special > > > casing of backing file in generic code? I'm not convinced either > > > way... > > > > You definitely want to guarantee that remounting filesystem r/o > > prevents the changes of visible contents; it's not just POSIX, > > it's a fairly basic common assumption about any local filesystems. > > Incidentally, could we simply keep a reference to original struct file > instead of messing with path? > > The only caller of backing_file_open() gets &file->f_path as user_path; how > about passing file instead, and having backing_file_open() do get_file() > on it and stash the sucker into your object? > > And have put_file_access() do > if (unlikely(file->f_mode & FMODE_BACKING)) > fput(backing_file(file)->file); > in the end. > > No need to mess with write access in any special way and it's closer > to the semantics we have for normal mmap(), after all - it keeps the > file we'd passed to it open as long as mapping is there. > > Comments? Seems good to me. It also shrinks backing_file by one pointer. I think this patch can be an extra one after "fs: store real path instead of fake path in backing file f_path" Instead of changing storing of real_path to storing orig file in one change? If there are no objections, I will write it up. Thanks, Amir.
On Tue, 10 Oct 2023 at 19:41, Al Viro <viro@zeniv.linux.org.uk> wrote: > > On Tue, Oct 10, 2023 at 05:55:04PM +0100, Al Viro wrote: > > On Tue, Oct 10, 2023 at 03:34:45PM +0200, Miklos Szeredi wrote: > > > On Tue, 10 Oct 2023 at 15:17, Amir Goldstein <amir73il@gmail.com> wrote: > > > > > > > Sorry, you asked about ovl mount. > > > > To me it makes sense that if users observe ovl paths in writable mapped > > > > memory, that ovl should not be remounted RO. > > > > Anyway, I don't see a good reason to allow remount RO for ovl in that case. > > > > Is there? > > > > > > Agreed. > > > > > > But is preventing remount RO important enough to warrant special > > > casing of backing file in generic code? I'm not convinced either > > > way... > > > > You definitely want to guarantee that remounting filesystem r/o > > prevents the changes of visible contents; it's not just POSIX, > > it's a fairly basic common assumption about any local filesystems. > > Incidentally, could we simply keep a reference to original struct file > instead of messing with path? > > The only caller of backing_file_open() gets &file->f_path as user_path; how > about passing file instead, and having backing_file_open() do get_file() > on it and stash the sucker into your object? > > And have put_file_access() do > if (unlikely(file->f_mode & FMODE_BACKING)) > fput(backing_file(file)->file); > in the end. That's much nicer, I like it. Thanks, Miklos
On Tue, Oct 10, 2023 at 08:57:21PM +0300, Amir Goldstein wrote: > On Tue, Oct 10, 2023 at 8:41 PM Al Viro <viro@zeniv.linux.org.uk> wrote: > > > > On Tue, Oct 10, 2023 at 05:55:04PM +0100, Al Viro wrote: > > > On Tue, Oct 10, 2023 at 03:34:45PM +0200, Miklos Szeredi wrote: > > > > On Tue, 10 Oct 2023 at 15:17, Amir Goldstein <amir73il@gmail.com> wrote: > > > > > > > > > Sorry, you asked about ovl mount. > > > > > To me it makes sense that if users observe ovl paths in writable mapped > > > > > memory, that ovl should not be remounted RO. > > > > > Anyway, I don't see a good reason to allow remount RO for ovl in that case. > > > > > Is there? > > > > > > > > Agreed. > > > > > > > > But is preventing remount RO important enough to warrant special > > > > casing of backing file in generic code? I'm not convinced either > > > > way... > > > > > > You definitely want to guarantee that remounting filesystem r/o > > > prevents the changes of visible contents; it's not just POSIX, > > > it's a fairly basic common assumption about any local filesystems. > > > > Incidentally, could we simply keep a reference to original struct file > > instead of messing with path? > > > > The only caller of backing_file_open() gets &file->f_path as user_path; how > > about passing file instead, and having backing_file_open() do get_file() > > on it and stash the sucker into your object? > > > > And have put_file_access() do > > if (unlikely(file->f_mode & FMODE_BACKING)) > > fput(backing_file(file)->file); > > in the end. > > > > No need to mess with write access in any special way and it's closer > > to the semantics we have for normal mmap(), after all - it keeps the > > file we'd passed to it open as long as mapping is there. > > > > Comments? > > Seems good to me. > It also shrinks backing_file by one pointer. > > I think this patch can be an extra one after > "fs: store real path instead of fake path in backing file f_path" > > Instead of changing storing of real_path to storing orig file in > one change? > > If there are no objections, I will write it up. Actually, now that I'd looked at it a bit more... Look: we don't need to do *anything* in put_file_access(); just make file_free() if (unlikely(f->f_mode & FMODE_BACKING)) fput(backing_file(f)->user_file); instead of conditional path_put(). That + change of open_backing_file() prototype + get_file() in there pretty much eliminates the work done in 1/3 - you don't need to mess with {get,put}_file_write_access() at all. I'd start with this: struct file *vm_user_file(struct vm_area_struct *vma) { return vma->vm_file; } + replace file = vma->vm_file; with file = vm_user_file(vma) in the places affected by your 2/3. That's the first (obviously safe) commit. Then the change of backing_file_open() combined with making vm_user_file() do this: file = vma->vm_file; if (file && unlikely(file->f_mode & FMODE_BACKING)) file = backing_file(file)->user_file; return file; Voila. Two-commit series, considerably smaller than your variant...
On Tue, Oct 10, 2023 at 9:21 PM Al Viro <viro@zeniv.linux.org.uk> wrote: > > On Tue, Oct 10, 2023 at 08:57:21PM +0300, Amir Goldstein wrote: > > On Tue, Oct 10, 2023 at 8:41 PM Al Viro <viro@zeniv.linux.org.uk> wrote: > > > > > > On Tue, Oct 10, 2023 at 05:55:04PM +0100, Al Viro wrote: > > > > On Tue, Oct 10, 2023 at 03:34:45PM +0200, Miklos Szeredi wrote: > > > > > On Tue, 10 Oct 2023 at 15:17, Amir Goldstein <amir73il@gmail.com> wrote: > > > > > > > > > > > Sorry, you asked about ovl mount. > > > > > > To me it makes sense that if users observe ovl paths in writable mapped > > > > > > memory, that ovl should not be remounted RO. > > > > > > Anyway, I don't see a good reason to allow remount RO for ovl in that case. > > > > > > Is there? > > > > > > > > > > Agreed. > > > > > > > > > > But is preventing remount RO important enough to warrant special > > > > > casing of backing file in generic code? I'm not convinced either > > > > > way... > > > > > > > > You definitely want to guarantee that remounting filesystem r/o > > > > prevents the changes of visible contents; it's not just POSIX, > > > > it's a fairly basic common assumption about any local filesystems. > > > > > > Incidentally, could we simply keep a reference to original struct file > > > instead of messing with path? > > > > > > The only caller of backing_file_open() gets &file->f_path as user_path; how > > > about passing file instead, and having backing_file_open() do get_file() > > > on it and stash the sucker into your object? > > > > > > And have put_file_access() do > > > if (unlikely(file->f_mode & FMODE_BACKING)) > > > fput(backing_file(file)->file); > > > in the end. > > > > > > No need to mess with write access in any special way and it's closer > > > to the semantics we have for normal mmap(), after all - it keeps the > > > file we'd passed to it open as long as mapping is there. > > > > > > Comments? > > > > Seems good to me. > > It also shrinks backing_file by one pointer. > > > > I think this patch can be an extra one after > > "fs: store real path instead of fake path in backing file f_path" > > > > Instead of changing storing of real_path to storing orig file in > > one change? > > > > If there are no objections, I will write it up. > > Actually, now that I'd looked at it a bit more... Look: > we don't need to do *anything* in put_file_access(); just > make file_free() > if (unlikely(f->f_mode & FMODE_BACKING)) > fput(backing_file(f)->user_file); > instead of conditional path_put(). That + change of open_backing_file() > prototype + get_file() in there pretty much eliminates the work done > in 1/3 - you don't need to mess with {get,put}_file_write_access() > at all. > > I'd start with this: > > struct file *vm_user_file(struct vm_area_struct *vma) > { > return vma->vm_file; > } > + replace file = vma->vm_file; with file = vm_user_file(vma) in > the places affected by your 2/3. That's the first (obviously > safe) commit. Then the change of backing_file_open() combined > with making vm_user_file() do this: > file = vma->vm_file; > if (file && unlikely(file->f_mode & FMODE_BACKING)) > file = backing_file(file)->user_file; > return file; > > Voila. Two-commit series, considerably smaller than your > variant... > Yap. looks very nice. I will try that out tomorrow. Anyway, it doesn't hurt to have the current version in linux-next for the night to see if the change from fake f_path to real f_path has any unexpected outcomes. Thanks for the suggestions! Amir.
On Tue, Oct 10, 2023 at 09:28:41PM +0300, Amir Goldstein wrote: > > with making vm_user_file() do this: > > file = vma->vm_file; > > if (file && unlikely(file->f_mode & FMODE_BACKING)) > > file = backing_file(file)->user_file; > > return file; > > > > Voila. Two-commit series, considerably smaller than your > > variant... > > > > Yap. looks very nice. > I will try that out tomorrow. > > Anyway, it doesn't hurt to have the current version in linux-next > for the night to see if the change from fake f_path to real f_path > has any unexpected outcomes. There is an obvious problem with that approach - refcounts don't mix with loops ;-/ Sorry about the noise - this really won't work.
On Tue, Oct 10, 2023 at 08:14:15PM +0200, Miklos Szeredi wrote: > On Tue, 10 Oct 2023 at 19:41, Al Viro <viro@zeniv.linux.org.uk> wrote: > > > > On Tue, Oct 10, 2023 at 05:55:04PM +0100, Al Viro wrote: > > > On Tue, Oct 10, 2023 at 03:34:45PM +0200, Miklos Szeredi wrote: > > > > On Tue, 10 Oct 2023 at 15:17, Amir Goldstein <amir73il@gmail.com> wrote: > > > > > > > > > Sorry, you asked about ovl mount. > > > > > To me it makes sense that if users observe ovl paths in writable mapped > > > > > memory, that ovl should not be remounted RO. > > > > > Anyway, I don't see a good reason to allow remount RO for ovl in that case. > > > > > Is there? > > > > > > > > Agreed. > > > > > > > > But is preventing remount RO important enough to warrant special > > > > casing of backing file in generic code? I'm not convinced either > > > > way... > > > > > > You definitely want to guarantee that remounting filesystem r/o > > > prevents the changes of visible contents; it's not just POSIX, > > > it's a fairly basic common assumption about any local filesystems. > > > > Incidentally, could we simply keep a reference to original struct file > > instead of messing with path? > > > > The only caller of backing_file_open() gets &file->f_path as user_path; how > > about passing file instead, and having backing_file_open() do get_file() > > on it and stash the sucker into your object? > > > > And have put_file_access() do > > if (unlikely(file->f_mode & FMODE_BACKING)) > > fput(backing_file(file)->file); > > in the end. > > That's much nicer, I like it. Won't work, unfortunately ;-/ We have the damn thing created on open(); it really can't pin the original file, or we'll never get to closing it. I don't think this approach could be salvaged - we could make that reference non-counting outside of mmap(), but we have no good way to catch the moment when it should be dropped; not without intercepting vm_ops->close() (and thus vm_ops->open() as well)... Oh, well..
diff --git a/fs/file_table.c b/fs/file_table.c index 08fd1dd6d863..fa92743ba6a9 100644 --- a/fs/file_table.c +++ b/fs/file_table.c @@ -44,10 +44,10 @@ static struct kmem_cache *filp_cachep __read_mostly; static struct percpu_counter nr_files __cacheline_aligned_in_smp; -/* Container for backing file with optional real path */ +/* Container for backing file with optional user path */ struct backing_file { struct file file; - struct path real_path; + struct path user_path; }; static inline struct backing_file *backing_file(struct file *f) @@ -55,11 +55,11 @@ static inline struct backing_file *backing_file(struct file *f) return container_of(f, struct backing_file, file); } -struct path *backing_file_real_path(struct file *f) +struct path *backing_file_user_path(struct file *f) { - return &backing_file(f)->real_path; + return &backing_file(f)->user_path; } -EXPORT_SYMBOL_GPL(backing_file_real_path); +EXPORT_SYMBOL_GPL(backing_file_user_path); static inline void file_free(struct file *f) { @@ -68,7 +68,7 @@ static inline void file_free(struct file *f) percpu_counter_dec(&nr_files); put_cred(f->f_cred); if (unlikely(f->f_mode & FMODE_BACKING)) { - path_put(backing_file_real_path(f)); + path_put(backing_file_user_path(f)); kfree(backing_file(f)); } else { kmem_cache_free(filp_cachep, f); diff --git a/fs/internal.h b/fs/internal.h index 4e93a685bdaa..58e43341aebf 100644 --- a/fs/internal.h +++ b/fs/internal.h @@ -101,7 +101,7 @@ static inline void file_put_write_access(struct file *file) put_write_access(file->f_inode); mnt_put_write_access(file->f_path.mnt); if (unlikely(file->f_mode & FMODE_BACKING)) - mnt_put_write_access(backing_file_real_path(file)->mnt); + mnt_put_write_access(backing_file_user_path(file)->mnt); } static inline void put_file_access(struct file *file) diff --git a/fs/open.c b/fs/open.c index fe63e236da22..02dc608d40d8 100644 --- a/fs/open.c +++ b/fs/open.c @@ -881,7 +881,7 @@ static inline int file_get_write_access(struct file *f) if (unlikely(error)) goto cleanup_inode; if (unlikely(f->f_mode & FMODE_BACKING)) { - error = mnt_get_write_access(backing_file_real_path(f)->mnt); + error = mnt_get_write_access(backing_file_user_path(f)->mnt); if (unlikely(error)) goto cleanup_mnt; } @@ -1182,20 +1182,19 @@ EXPORT_SYMBOL_GPL(kernel_file_open); /** * backing_file_open - open a backing file for kernel internal use - * @path: path of the file to open + * @user_path: path that the user reuqested to open * @flags: open flags * @real_path: path of the backing file * @cred: credentials for open * * Open a backing file for a stackable filesystem (e.g., overlayfs). - * @path may be on the stackable filesystem and backing inode on the - * underlying filesystem. In this case, we want to be able to return - * the @real_path of the backing inode. This is done by embedding the - * returned file into a container structure that also stores the path of - * the backing inode on the underlying filesystem, which can be - * retrieved using backing_file_real_path(). + * @user_path may be on the stackable filesystem and @real_path on the + * underlying filesystem. In this case, we want to be able to return the + * @user_path of the stackable filesystem. This is done by embedding the + * returned file into a container structure that also stores the stacked + * file's path, which can be retrieved using backing_file_user_path(). */ -struct file *backing_file_open(const struct path *path, int flags, +struct file *backing_file_open(const struct path *user_path, int flags, const struct path *real_path, const struct cred *cred) { @@ -1206,9 +1205,9 @@ struct file *backing_file_open(const struct path *path, int flags, if (IS_ERR(f)) return f; - f->f_path = *path; - path_get(real_path); - *backing_file_real_path(f) = *real_path; + path_get(user_path); + *backing_file_user_path(f) = *user_path; + f->f_path = *real_path; error = do_dentry_open(f, d_inode(real_path->dentry), NULL); if (error) { fput(f); diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c index 3fa2416264a4..400a925a8ad2 100644 --- a/fs/overlayfs/super.c +++ b/fs/overlayfs/super.c @@ -34,14 +34,22 @@ static struct dentry *ovl_d_real(struct dentry *dentry, struct dentry *real = NULL, *lower; int err; - /* It's an overlay file */ + /* + * vfs is only expected to call d_real() with NULL from d_real_inode() + * and with overlay inode from file_dentry() on an overlay file. + * + * TODO: remove @inode argument from d_real() API, remove code in this + * function that deals with non-NULL @inode and remove d_real() call + * from file_dentry(). + */ if (inode && d_inode(dentry) == inode) return dentry; + else if (inode) + goto bug; if (!d_is_reg(dentry)) { - if (!inode || inode == d_inode(dentry)) - return dentry; - goto bug; + /* d_real_inode() is only relevant for regular files */ + return dentry; } real = ovl_dentry_upper(dentry); diff --git a/include/linux/fs.h b/include/linux/fs.h index a8e4e1cac48e..b0624d83c2db 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -2451,26 +2451,10 @@ struct file *dentry_open(const struct path *path, int flags, const struct cred *creds); struct file *dentry_create(const struct path *path, int flags, umode_t mode, const struct cred *cred); -struct file *backing_file_open(const struct path *path, int flags, +struct file *backing_file_open(const struct path *user_path, int flags, const struct path *real_path, const struct cred *cred); -struct path *backing_file_real_path(struct file *f); - -/* - * file_real_path - get the path corresponding to f_inode - * - * When opening a backing file for a stackable filesystem (e.g., - * overlayfs) f_path may be on the stackable filesystem and f_inode on - * the underlying filesystem. When the path associated with f_inode is - * needed, this helper should be used instead of accessing f_path - * directly. -*/ -static inline const struct path *file_real_path(struct file *f) -{ - if (unlikely(f->f_mode & FMODE_BACKING)) - return backing_file_real_path(f); - return &f->f_path; -} +struct path *backing_file_user_path(struct file *f); /* * file_user_path - get the path to display for memory mapped file @@ -2483,6 +2467,8 @@ static inline const struct path *file_real_path(struct file *f) */ static inline const struct path *file_user_path(struct file *f) { + if (unlikely(f->f_mode & FMODE_BACKING)) + return backing_file_user_path(f); return &f->f_path; } diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h index ed48e4f1e755..bcb6609b54b3 100644 --- a/include/linux/fsnotify.h +++ b/include/linux/fsnotify.h @@ -96,8 +96,7 @@ static inline int fsnotify_file(struct file *file, __u32 mask) if (file->f_mode & FMODE_NONOTIFY) return 0; - /* Overlayfs internal files have fake f_path */ - path = file_real_path(file); + path = &file->f_path; return fsnotify_parent(path->dentry, mask, path, FSNOTIFY_EVENT_PATH); }
A backing file struct stores two path's, one "real" path that is referring to f_inode and one "fake" path, which should be displayed to users in /proc/<pid>/maps. There is a lot more potential code that needs to know the "real" path, then code that needs to know the "fake" path. Instead of code having to request the "real" path with file_real_path(), store the "real" path in f_path and require code that needs to know the "fake" path request it with file_user_path(). Replace the file_real_path() helper with a simple const accessor f_path(). After this change, file_dentry() is not expected to observe any files with overlayfs f_path and real f_inode, so the call to ->d_real() should not be needed. Leave the ->d_real() call for now and add an assertion in ovl_d_real() to catch if we made wrong assumptions. Suggested-by: Miklos Szeredi <miklos@szeredi.hu> Link: https://lore.kernel.org/r/CAJfpegtt48eXhhjDFA1ojcHPNKj3Go6joryCPtEFAKpocyBsnw@mail.gmail.com/ Signed-off-by: Amir Goldstein <amir73il@gmail.com> --- fs/file_table.c | 12 ++++++------ fs/internal.h | 2 +- fs/open.c | 23 +++++++++++------------ fs/overlayfs/super.c | 16 ++++++++++++---- include/linux/fs.h | 22 ++++------------------ include/linux/fsnotify.h | 3 +-- 6 files changed, 35 insertions(+), 43 deletions(-)