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

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

 



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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux