[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 4:10 PM Amir Goldstein <amir73il at gmail.com> wrote:
>
> 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?
>

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.