From: Luis Henriques <lhenriques@suse.com>
To: Jeff Layton <jlayton@kernel.org>
Cc: ceph-devel@vger.kernel.org
Subject: Re: Help understanding xfstest generic/467 failure
Date: Tue, 12 May 2020 17:11:27 +0100 [thread overview]
Message-ID: <20200512161127.GA57099@suse.com> (raw)
In-Reply-To: <ef6459452ab8156d69e2b41b35f3d388d7a3197c.camel@kernel.org>
On Tue, May 12, 2020 at 11:33:13AM -0400, Jeff Layton wrote:
> On Tue, 2020-05-12 at 16:13 +0100, Luis Henriques wrote:
> > Hi Jeff,
> >
> > I've been looking at xfstest generic/467 failure in cephfs, and I simply
> > can not decide if it's a genuine bug on ceph kernel code. Since you've
> > recently been touching the ceph_unlink code maybe you could help me
> > understanding what's going on.
> >
> > generic/467 runs a couple of tests using src/open_by_handle, but the one
> > failing can be summarized with the following:
> >
> > - get a handle to /cephfs/myfile using name_to_handle_at(2)
> > - open(2) file /cephfs/myfile
> > - unlink(2) /cephfs/myfile
> > - drop caches
> > - open_by_handle_at(2) => returns -ESTALE
> >
> > This test succeeds opening the handle with other (local) filesystems
> > (maybe I should run it with other networked filesystem such as NFS).
> >
> > The -ESTALE is easy to trace to __fh_to_dentry, where inode->i_nlink is
> > checked against 0. My question is: should we really be testing the
> > i_nlink here? We dropped the name, but the file may still be there (as in
> > this case).
> >
> > I guess I'm missing something, but hopefully you'll be able to shed some
> > light on this. Thanks in advance for any help you may provide!
>
> Yeah, I took a brief look at this a while back and never got back to
> looking at it again. I think cephfs's behavior is wrong here. We should
> be able to look up an open-but-unlinked file by filehandle.
>
> That said those checks went in via commit 570df4e9c23f8, and it looks
> like it was deliberately added to __fh_to_dentry. I'm unclear as to why.
Right, I saw that commit too and that check came from the 'old' version of
ceph_lookup_inode into the 'new' version of ceph_lookup_inode and into
__fh_to_dentry.
> It may be interesting to remove the i_nlink checks and see whether it
> breaks anything?
I've done that already and a very quick test didn't show anything. But it
may break things a very subtle ways. I'll see if it's able to handle a
full run of xfstests.
Thanks for your hints, Jeff. I'll see if I can progress a bit further on
this.
Cheers,
--
Luis
prev parent reply other threads:[~2020-05-12 16:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-12 15:13 Help understanding xfstest generic/467 failure Luis Henriques
2020-05-12 15:33 ` Jeff Layton
2020-05-12 16:11 ` Luis Henriques [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=20200512161127.GA57099@suse.com \
--to=lhenriques@suse.com \
--cc=ceph-devel@vger.kernel.org \
--cc=jlayton@kernel.org \
/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.