linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miklos Szeredi <miklos@szeredi.hu>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Miklos Szeredi <mszeredi@redhat.com>,
	overlayfs <linux-unionfs@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 4/4] ovl: alllow remote upper
Date: Tue, 4 Feb 2020 17:16:49 +0100	[thread overview]
Message-ID: <CAJfpegtq4A-m9vOPwUftiotC_Xv6w-dnhCi9=E0t-b1ZPJXPGw@mail.gmail.com> (raw)
In-Reply-To: <20200204145951.GC11631@redhat.com>

On Tue, Feb 4, 2020 at 3:59 PM Vivek Goyal <vgoyal@redhat.com> wrote:
>
> On Fri, Jan 31, 2020 at 12:50:04PM +0100, Miklos Szeredi wrote:
> > No reason to prevent upper layer being a remote filesystem.  Do the
> > revalidation in that case, just as we already do for lower layers.
> >
> > This lets virtiofs be used as upper layer, which appears to be a real use
> > case.
>
> Hi Miklos,
>
> I have couple of very basic questions.
>
> - So with this change, we will allow NFS to be upper layer also?

I haven't tested, but I think it will fail on the d_type test.

> - What does revalidation on lower/upper mean? Does that mean that
>   lower/upper can now change underneath overlayfs and overlayfs will
>   cope with it.

No, that's a more complicated thing.  Especially with redirected
layers (i.e. revalidating a redirect actually means revalidating all
the path components of that redirect).

> If we still expect underlying layers not to change, then
>   what's the point of calling ->revalidate().

That's a good question; I guess because that's what the filesystem
expects.  OTOH, it's probably unnecessary in most cases, since the
path could come from an open file descriptor, in which case the vfs
will not do any revalidation on that path.

So this is basically done to be on the safe side, but it might not be necessary.

Thanks,
Miklos

> Thanks
> Vivek
>
> >
> > Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
> > ---
> >  fs/overlayfs/namei.c | 3 +--
> >  fs/overlayfs/super.c | 8 ++++++--
> >  fs/overlayfs/util.c  | 2 ++
> >  3 files changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c
> > index 76e61cc27822..0db23baf98e7 100644
> > --- a/fs/overlayfs/namei.c
> > +++ b/fs/overlayfs/namei.c
> > @@ -845,8 +845,7 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry,
> >               if (err)
> >                       goto out;
> >
> > -             if (upperdentry && (upperdentry->d_flags & DCACHE_OP_REAL ||
> > -                                 unlikely(ovl_dentry_remote(upperdentry)))) {
> > +             if (upperdentry && upperdentry->d_flags & DCACHE_OP_REAL) {
> >                       dput(upperdentry);
> >                       err = -EREMOTE;
> >                       goto out;
> > diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
> > index 26d4153240a8..ed3a11db9039 100644
> > --- a/fs/overlayfs/super.c
> > +++ b/fs/overlayfs/super.c
> > @@ -135,9 +135,14 @@ static int ovl_dentry_revalidate_common(struct dentry *dentry,
> >                                       unsigned int flags, bool weak)
> >  {
> >       struct ovl_entry *oe = dentry->d_fsdata;
> > +     struct dentry *upper;
> >       unsigned int i;
> >       int ret = 1;
> >
> > +     upper = ovl_dentry_upper(dentry);
> > +     if (upper)
> > +             ret = ovl_revalidate_real(upper, flags, weak);
> > +
> >       for (i = 0; ret > 0 && i < oe->numlower; i++) {
> >               ret = ovl_revalidate_real(oe->lowerstack[i].dentry, flags,
> >                                         weak);
> > @@ -747,8 +752,7 @@ static int ovl_mount_dir(const char *name, struct path *path)
> >               ovl_unescape(tmp);
> >               err = ovl_mount_dir_noesc(tmp, path);
> >
> > -             if (!err && (ovl_dentry_remote(path->dentry) ||
> > -                          path->dentry->d_flags & DCACHE_OP_REAL)) {
> > +             if (!err && path->dentry->d_flags & DCACHE_OP_REAL) {
> >                       pr_err("filesystem on '%s' not supported as upperdir\n",
> >                              tmp);
> >                       path_put_init(path);
> > diff --git a/fs/overlayfs/util.c b/fs/overlayfs/util.c
> > index 3ad8fb291f7d..c793722739e1 100644
> > --- a/fs/overlayfs/util.c
> > +++ b/fs/overlayfs/util.c
> > @@ -96,6 +96,8 @@ void ovl_dentry_update_reval(struct dentry *dentry, struct dentry *upperdentry,
> >       struct ovl_entry *oe = OVL_E(dentry);
> >       unsigned int i, flags = 0;
> >
> > +     if (upperdentry)
> > +             flags |= upperdentry->d_flags;
> >       for (i = 0; i < oe->numlower; i++)
> >               flags |= oe->lowerstack[i].dentry->d_flags;
> >
> > --
> > 2.21.1
> >
>

  reply	other threads:[~2020-02-04 16:17 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-31 11:50 [PATCH 0/4] ovl: allow virtiofs as upper Miklos Szeredi
2020-01-31 11:50 ` [PATCH 1/4] ovl: restructure dentry revalidation Miklos Szeredi
2020-01-31 11:50 ` [PATCH 2/4] ovl: separate detection of remote upper layer from stacked overlay Miklos Szeredi
2020-01-31 11:50 ` [PATCH 3/4] ovl: decide if revalidate needed on a per-dentry bases Miklos Szeredi
2020-01-31 14:53   ` Amir Goldstein
2020-01-31 15:15     ` Miklos Szeredi
2020-01-31 11:50 ` [PATCH 4/4] ovl: alllow remote upper Miklos Szeredi
2020-01-31 15:29   ` Amir Goldstein
2020-01-31 15:38     ` Miklos Szeredi
2020-01-31 15:50       ` Amir Goldstein
2020-01-31 16:05         ` Miklos Szeredi
2020-02-04 14:59   ` Vivek Goyal
2020-02-04 16:16     ` Miklos Szeredi [this message]
2020-02-04 17:02       ` Amir Goldstein
2020-02-04 18:42         ` Vivek Goyal
2020-02-04 19:11           ` Amir Goldstein
2020-02-04 19:16             ` Miklos Szeredi
2020-02-20  7:52         ` Amir Goldstein
2020-02-20 20:00           ` Amir Goldstein
2020-03-14 13:16             ` Amir Goldstein
2020-03-16 17:54               ` Vivek Goyal
2020-03-16 19:02                 ` Amir Goldstein
2020-03-16 19:40                   ` Vivek Goyal
2020-03-18 13:36                   ` unionmount testsuite with upper virtiofs Amir Goldstein
2020-03-19 21:40                     ` Vivek Goyal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJfpegtq4A-m9vOPwUftiotC_Xv6w-dnhCi9=E0t-b1ZPJXPGw@mail.gmail.com' \
    --to=miklos@szeredi.hu \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    --cc=vgoyal@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).