[PATCH v3 3/3] fs: store real path instead of fake path in backing file f_path

[Amir Goldstein]

On Tue, Oct 10, 2023 at 2:59 PM Miklos Szeredi <miklos at szeredi.hu> wrote:
>
> On Mon, 9 Oct 2023 at 17:37, Amir Goldstein <amir73il at 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.