From: David Howells <dhowells@redhat.com>
To: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Cc: dhowells@redhat.com, "slava@dubeyko.com" <slava@dubeyko.com>,
Xiubo Li <xiubli@redhat.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>,
"brauner@kernel.org" <brauner@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Alex Markuze <amarkuze@redhat.com>,
"jlayton@kernel.org" <jlayton@kernel.org>,
"idryomov@gmail.com" <idryomov@gmail.com>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>
Subject: Re: Does ceph_fill_inode() mishandle I_NEW?
Date: Thu, 13 Mar 2025 23:47:51 +0000 [thread overview]
Message-ID: <1675858.1741909671@warthog.procyon.org.uk> (raw)
In-Reply-To: <afeb9082273098f47b26371a7e252381d1268c8e.camel@ibm.com>
Viacheslav Dubeyko <Slava.Dubeyko@ibm.com> wrote:
> As far as I can see, ceph_fill_inode() has comment: "Populate an inode based
> on info from mds. May be called on new or existing inodes". It sounds to me
> that particular CephFS kernel client could have obsolete state of inode
> compared with MDS's state. And we need to "re-new" the existing inode with
> the actual state that we received from MDS side. My vision is that we need
> to take into account the distributed nature of Ceph and inode metadata can
> be updated from multiple CephFS kernel client instances. Am I right here?
As I mentioned in my reply to Jeff, I'm thinking of what happens in the event
that we have a file that has hard links in several directories in a situation
where several of those links are looked up simultaneously. Can we end up with
ceph_fill_inode() being run in parallel on several threads on the same inode?
Actually, the use of ci->i_ceph_lock looks like it should make it safe, now
that I look at it again.
David
next prev parent reply other threads:[~2025-03-13 23:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-13 10:17 Does ceph_fill_inode() mishandle I_NEW? David Howells
2025-03-13 19:14 ` slava
2025-03-13 20:47 ` David Howells
2025-03-13 21:46 ` Viacheslav Dubeyko
2025-03-13 23:47 ` David Howells [this message]
2025-03-13 22:47 ` Jeff Layton
2025-03-13 23:37 ` David Howells
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=1675858.1741909671@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=Slava.Dubeyko@ibm.com \
--cc=amarkuze@redhat.com \
--cc=brauner@kernel.org \
--cc=ceph-devel@vger.kernel.org \
--cc=idryomov@gmail.com \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=slava@dubeyko.com \
--cc=viro@zeniv.linux.org.uk \
--cc=xiubli@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 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.