CEPH filesystem development
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: "Yan, Zheng" <zyan@redhat.com>
Cc: ceph-devel <ceph-devel@vger.kernel.org>,
	Ilya Dryomov <idryomov@gmail.com>, Sage Weil <sage@redhat.com>,
	donatas.abraitis@gmail.com, viro@zeniv.linux.org.uk
Subject: Re: [PATCH] ceph: don't set req->r_locked_dir in ceph_d_revalidate
Date: Mon, 05 Dec 2016 06:47:26 -0500	[thread overview]
Message-ID: <1480938446.2544.4.camel@redhat.com> (raw)
In-Reply-To: <415F6BA5-3FA3-45FD-A709-C438B4EACE3C@redhat.com>

On Mon, 2016-12-05 at 10:28 +0800, Yan, Zheng wrote:
> > 
> > On 3 Dec 2016, at 00:52, Jeff Layton <jlayton@redhat.com> wrote:
> > 
> > This function sets req->r_locked_dir which is supposed to indicate to
> > ceph_fill_trace that the parent's i_rwsem is locked for write.
> > Unfortunately, there is no guarantee that the dir will be locked when
> > d_revalidate is called, so we really don't want ceph_fill_trace to do
> > any dcache manipulation from this context. Clear req->r_locked_dir since
> > it's clearly not safe to do that.
> > 
> > What we really want to know with d_revalidate is whether the dentry
> > still points to the same inode. ceph_fill_trace installs a pointer to
> > the inode in req->r_target_inode, so we can just compare that to
> > d_inode(dentry) to see if it's the same one after the lookup.
> > 
> > Also, since we aren't generally interested in the parent here, we can
> > switch to using a GETATTR to hint that to the MDS, which also means that
> > we only need to reserve one cap.
> > 
> > Finally, just remove the d_unhashed check. That's really outside the
> > purview of a filesystem's d_revalidate. If the thing became unhashed
> > while we're checking it, then that's up to the VFS to handle anyway.
> > 
> > Fixes: 200fd27c8fa2 (ceph: use lookup request to revalidate dentry)
> > Reported-by: Donatas Abraitis <donatas.abraitis@gmail.com>
> > Cc: stable@vger.kernel.org # v4.6+
> > Signed-off-by: Jeff Layton <jlayton@redhat.com>
> > ---
> > fs/ceph/dir.c | 24 ++++++++++++++----------
> > 1 file changed, 14 insertions(+), 10 deletions(-)
> > 
> > diff --git a/fs/ceph/dir.c b/fs/ceph/dir.c
> > index 78180d151730..a594c7879cc2 100644
> > --- a/fs/ceph/dir.c
> > +++ b/fs/ceph/dir.c
> > @@ -1261,26 +1261,30 @@ static int ceph_d_revalidate(struct dentry *dentry, unsigned int flags)
> > 			return -ECHILD;
> > 
> > 		op = ceph_snap(dir) == CEPH_SNAPDIR ?
> > -			CEPH_MDS_OP_LOOKUPSNAP : CEPH_MDS_OP_LOOKUP;
> > +			CEPH_MDS_OP_LOOKUPSNAP : CEPH_MDS_OP_GETATTR;
> > 		req = ceph_mdsc_create_request(mdsc, op, USE_ANY_MDS);
> > 		if (!IS_ERR(req)) {
> > 			req->r_dentry = dget(dentry);
> > -			req->r_num_caps = 2;
> > +			req->r_num_caps = op == CEPH_MDS_OP_GETATTR ? 1 : 2;
> > 
> > 			mask = CEPH_STAT_CAP_INODE | CEPH_CAP_AUTH_SHARED;
> > 			if (ceph_security_xattr_wanted(dir))
> > 				mask |= CEPH_CAP_XATTR_SHARED;
> > 			req->r_args.getattr.mask = mask;
> > 
> > -			req->r_locked_dir = dir;
> > 			err = ceph_mdsc_do_request(mdsc, NULL, req);
> > -			if (err == 0 || err == -ENOENT) {
> > -				if (dentry == req->r_dentry) {
> > -					valid = !d_unhashed(dentry);
> > -				} else {
> > -					d_invalidate(req->r_dentry);
> > -					err = -EAGAIN;
> > -				}
> > +			switch (err) {
> > +			case 0:
> > +				if (d_really_is_positive(dentry) &&
> > +				    d_inode(dentry) == req->r_target_inode)
> > +					valid = 1;
> > +				break;
> > +			case -ENOENT:
> > +				if (d_really_is_negative(dentry))
> > +					valid = 1;
> > +				/* Fallthrough */
> > +			default:
> > +				break;
> > 			}
> > 			ceph_mdsc_put_request(req);
> > 			dout("d_revalidate %p lookup result=%d\n”,
> 
> Looks good. As we discussed, please write a patch that guarantees safe access to d_parent when parent is not locked.
> (__choose_mds, build_dentry_path and probably ceph_encode_dentry_release)
> 
> Regards
> Yan, Zheng
> 

Thanks. I'll add your Reviewed-by and merge it into ceph-client.git if
that's ok.

The issue with parent stability while walking back up the tree is a
bigger problem, but is separate from this one. I'm still looking at
that...

-- 
Jeff Layton <jlayton@redhat.com>

      reply	other threads:[~2016-12-05 11:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-02 16:52 [PATCH] ceph: don't set req->r_locked_dir in ceph_d_revalidate Jeff Layton
2016-12-05  2:28 ` Yan, Zheng
2016-12-05 11:47   ` Jeff Layton [this message]

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=1480938446.2544.4.camel@redhat.com \
    --to=jlayton@redhat.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=donatas.abraitis@gmail.com \
    --cc=idryomov@gmail.com \
    --cc=sage@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=zyan@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