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.
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox