All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: overlayfs <linux-unionfs@vger.kernel.org>,
	Miklos Szeredi <miklos@szeredi.hu>
Subject: Re: [PATCH 1/3] ovl: Set d->last properly during lookup
Date: Fri, 9 Mar 2018 09:08:05 -0500	[thread overview]
Message-ID: <20180309140805.GA4596@redhat.com> (raw)
In-Reply-To: <CAOQ4uxiF4Kcva-iHj9PSd+wz9Xvy-bJP4GsbKY1WFnfH4pOZyQ@mail.gmail.com>

On Fri, Mar 09, 2018 at 12:25:01AM +0200, Amir Goldstein wrote:
> On Fri, Mar 9, 2018 at 12:18 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > d->last signifies that this is the last layer we are looking into and there
> > is no more. And that means this allows for some optimzation opportunities
> > during lookup. For example, in ovl_lookup_single() we don't have to check
> > for opaque xattr of a directory is this is the last layer we are looking
> > into (d->last = true).
> >
> > But knowing for sure whether we are looking into last layer can be very
> > tricky. If redirects are not enabled, then we can look at poe->numlower
> > and figure out if the lookup we are about to is last layer or not. But
> > if redircts are enabled then it is possible poe->numlower suggests that
> > we are looking in last layer, but there is an absolute redirect present
> > in found element and that redirects us to a layer in root and that means
> > lookup will continue in lower layers further.
> >
> > For example, consider following.
> >
> > /upperdir/pure (opaque=y)
> > /upperdir/pure/foo (opaque=y,redirect=/bar)
> > /lowerdir/bar
> >
> > In this case pure is "pure upper". When we look for "foo", that time
> > poe->numlower=0. But that alone does not mean that we will not search
> > for a merge candidate in /lowerdir. Absolute redirect changes that.
> >
> > IOW, d->last should not be set just based on poe->numlower if redirects
> > are enabled. That can lead to setting d->last while it should not have
> > and that means we will not check for opaque xattr while we should have.
> >
> > So do this.
> >
> > - If redirects are not enabled, then continue to rely on poe->numlower
> >   information to determine if it is last layer or not.
> >
> > - If redirects are enabled, then set d->last = true only if this is the
> >   last layer in root ovl_entry (roe).
> >
> > Suggested-by: Amir Goldstein <amir73il@gmail.com>
> > Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
> 
> Reviewed-by: Amir Goldstein <amir73il@gmail.com>
> 
> Much better description than my RFC patch :-)
> One minor error
> 
> > ---
> >  fs/overlayfs/namei.c | 8 ++++++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c
> > index de3e6da1d5a5..2e173cfbda0e 100644
> > --- a/fs/overlayfs/namei.c
> > +++ b/fs/overlayfs/namei.c
> > @@ -815,7 +815,7 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry,
> >                 .is_dir = false,
> >                 .opaque = false,
> >                 .stop = false,
> > -               .last = !poe->numlower,
> > +               .last = ofs->config.redirect_follow ? false : !poe->numlower,
> >                 .redirect = NULL,
> >         };
> >
> > @@ -873,7 +873,11 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry,
> >         for (i = 0; !d.stop && i < poe->numlower; i++) {
> >                 struct ovl_path lower = poe->lowerstack[i];
> >
> > -               d.last = i == poe->numlower - 1;
> > +               if (!ofs->config.redirect_follow)
> > +                       d.last = i == poe->numlower - 1;
> > +               else
> > +                       d.last = lower.layer->idx == roe->numlower - 1;
> > +
> 
> Should be lower.layer->idx == roe->numlower. (idx 0 is upper)

Ok, got it. I see following in super.c

ofs->lower_layers[ofs->numlower].idx = i + 1;

Will fix it.

Thanks
Vivek
> 
> But to be honest I did not verify that xattr checks are optimized away with
> my RFC patch, just that the test case above behaves as expected.
> 
> Thanks,
> Amir.

  reply	other threads:[~2018-03-09 14:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-08 22:18 [RFC PATCH 0/3] Misc ovl_lookup() related fixes Vivek Goyal
2018-03-08 22:18 ` [PATCH 1/3] ovl: Set d->last properly during lookup Vivek Goyal
2018-03-08 22:25   ` Amir Goldstein
2018-03-09 14:08     ` Vivek Goyal [this message]
2018-03-08 22:18 ` [PATCH 2/3] ovl: Do not check for redirect if this is last layer Vivek Goyal
2018-03-08 22:27   ` Amir Goldstein
2018-03-09 14:18     ` Vivek Goyal
2018-03-08 22:18 ` [PATCH 3/3] ovl: set d->is_dir and d->opaque for last path element Vivek Goyal
2018-03-08 22:34   ` Amir Goldstein
2018-03-09 14:44     ` Vivek Goyal
2018-03-09 15:20       ` Amir Goldstein
2018-03-09 16:30         ` Vivek Goyal
2018-03-09 16:38           ` Amir Goldstein
2018-03-09 16:44             ` 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=20180309140805.GA4596@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=amir73il@gmail.com \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.