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