On Thu, 2025-03-13 at 20:47 +0000, David Howells wrote: > slava@xxxxxxxxxxx wrote: > > > What do you mean by mishandling? Do you imply that Ceph has to set up > > the I_NEW somehow? Is it not VFS responsibility? > > No - I mean that if I_NEW *isn't* set when the function is called, > ceph_fill_inode() will go and partially reinitialise the inode. Now, having > reviewed the code in more depth and talked to Jeff Layton about it, I think > that the non-I_NEW pass will only change pointers with some sort of locking > and will release the old target - though it may overwrite some pointers with > the same value without protection (i_fops for example). > > That said, if it's possible for *two* processes to be going through that > function without I_NEW set, you can get places where both of them will try > freeing the old data and replacing it with new without any locking - but I > don't know if that can happen. > I see your point now. 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? Thanks, Slava.
