| Message ID | 20240328163424.2781320-2-dhowells@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | netfs, afs, 9p, cifs: Rework netfs to use ->writepages() to copy to cache | expand |
On Thu, 2024-03-28 at 16:33 +0000, David Howells wrote: > fscache emits a lot of duplicate cookie warnings with cifs because the > index key for the fscache cookies does not include everything that the > cifs_find_inode() function does. The latter is used with iget5_locked() to > distinguish between inodes in the local inode cache. > > Fix this by adding the creation time and file type to the fscache cookie > key. > > Additionally, add a couple of comments to note that if one is changed the > other must be also. > > Signed-off-by: David Howells <dhowells@redhat.com> > cc: Steve French <sfrench@samba.org> > cc: Shyam Prasad N <nspmangalore@gmail.com> > cc: Rohith Surabattula <rohiths.msft@gmail.com> > cc: Jeff Layton <jlayton@kernel.org> > cc: linux-cifs@vger.kernel.org > cc: netfs@lists.linux.dev > cc: linux-fsdevel@vger.kernel.org > --- > fs/smb/client/fscache.c | 16 +++++++++++++++- > fs/smb/client/inode.c | 2 ++ > 2 files changed, 17 insertions(+), 1 deletion(-) > > diff --git a/fs/smb/client/fscache.c b/fs/smb/client/fscache.c > index c4a3cb736881..340efce8f052 100644 > --- a/fs/smb/client/fscache.c > +++ b/fs/smb/client/fscache.c > @@ -12,6 +12,16 @@ > #include "cifs_fs_sb.h" > #include "cifsproto.h" > > +/* > + * Key for fscache inode. [!] Contents must match comparisons in cifs_find_inode(). > + */ > +struct cifs_fscache_inode_key { > + > + __le64 uniqueid; /* server inode number */ > + __le64 createtime; /* creation time on server */ > + u8 type; /* S_IFMT file type */ > +} __packed; > + Interesting. So the uniqueid of the inode is not unique within the fs? Or are the clients are mounting shares that span multiple filesystems? Or, are we looking at a situation where the uniqueid is being quickly reused for new inodes after the original inode is unlinked? Should we be mixing in a fsid (or whatever the windows equivalent is)? > static void cifs_fscache_fill_volume_coherency( > struct cifs_tcon *tcon, > struct cifs_fscache_volume_coherency_data *cd) > @@ -97,15 +107,19 @@ void cifs_fscache_release_super_cookie(struct cifs_tcon *tcon) > void cifs_fscache_get_inode_cookie(struct inode *inode) > { > struct cifs_fscache_inode_coherency_data cd; > + struct cifs_fscache_inode_key key; > struct cifsInodeInfo *cifsi = CIFS_I(inode); > struct cifs_sb_info *cifs_sb = CIFS_SB(inode->i_sb); > struct cifs_tcon *tcon = cifs_sb_master_tcon(cifs_sb); > > + key.uniqueid = cpu_to_le64(cifsi->uniqueid); > + key.createtime = cpu_to_le64(cifsi->createtime); > + key.type = (inode->i_mode & S_IFMT) >> 12; > cifs_fscache_fill_coherency(&cifsi->netfs.inode, &cd); > > cifsi->netfs.cache = > fscache_acquire_cookie(tcon->fscache, 0, > - &cifsi->uniqueid, sizeof(cifsi->uniqueid), > + &key, sizeof(key), > &cd, sizeof(cd), > i_size_read(&cifsi->netfs.inode)); > if (cifsi->netfs.cache) > diff --git a/fs/smb/client/inode.c b/fs/smb/client/inode.c > index d28ab0af6049..91b07ef9e25c 100644 > --- a/fs/smb/client/inode.c > +++ b/fs/smb/client/inode.c > @@ -1351,6 +1351,8 @@ cifs_find_inode(struct inode *inode, void *opaque) > { > struct cifs_fattr *fattr = opaque; > > + /* [!] The compared values must be the same in struct cifs_fscache_inode_key. */ > + > /* don't match inode with different uniqueid */ > if (CIFS_I(inode)->uniqueid != fattr->cf_uniqueid) > return 0; > Reviewed-by: Jeff Layton <jlayton@kernel.org>
Jeff Layton <jlayton@kernel.org> wrote: > > +struct cifs_fscache_inode_key { > > + > > + __le64 uniqueid; /* server inode number */ > > + __le64 createtime; /* creation time on server */ > > + u8 type; /* S_IFMT file type */ > > +} __packed; > > + > > Interesting. So the uniqueid of the inode is not unique within the fs? > Or are the clients are mounting shares that span multiple filesystems? > Or, are we looking at a situation where the uniqueid is being quickly > reused for new inodes after the original inode is unlinked? The problem is that it's not unique over time. creat(); unlink(); creat(); may yield a repeat of the uniqueid. It's like i_ino in that respect. David
Should this be merged independently (and sooner? in rc5?) On Mon, Apr 15, 2024 at 8:04 AM David Howells <dhowells@redhat.com> wrote: > > Jeff Layton <jlayton@kernel.org> wrote: > > > > +struct cifs_fscache_inode_key { > > > + > > > + __le64 uniqueid; /* server inode number */ > > > + __le64 createtime; /* creation time on server */ > > > + u8 type; /* S_IFMT file type */ > > > +} __packed; > > > + > > > > Interesting. So the uniqueid of the inode is not unique within the fs? > > Or are the clients are mounting shares that span multiple filesystems? > > Or, are we looking at a situation where the uniqueid is being quickly > > reused for new inodes after the original inode is unlinked? > > The problem is that it's not unique over time. creat(); unlink(); creat(); > may yield a repeat of the uniqueid. It's like i_ino in that respect. > > David >
Steve French <smfrench@gmail.com> wrote:
> Should this be merged independently (and sooner? in rc5?)
It's already upstream through the cifs tree and I've dropped it from my
branch.
David
diff --git a/fs/smb/client/fscache.c b/fs/smb/client/fscache.c index c4a3cb736881..340efce8f052 100644 --- a/fs/smb/client/fscache.c +++ b/fs/smb/client/fscache.c @@ -12,6 +12,16 @@ #include "cifs_fs_sb.h" #include "cifsproto.h" +/* + * Key for fscache inode. [!] Contents must match comparisons in cifs_find_inode(). + */ +struct cifs_fscache_inode_key { + + __le64 uniqueid; /* server inode number */ + __le64 createtime; /* creation time on server */ + u8 type; /* S_IFMT file type */ +} __packed; + static void cifs_fscache_fill_volume_coherency( struct cifs_tcon *tcon, struct cifs_fscache_volume_coherency_data *cd) @@ -97,15 +107,19 @@ void cifs_fscache_release_super_cookie(struct cifs_tcon *tcon) void cifs_fscache_get_inode_cookie(struct inode *inode) { struct cifs_fscache_inode_coherency_data cd; + struct cifs_fscache_inode_key key; struct cifsInodeInfo *cifsi = CIFS_I(inode); struct cifs_sb_info *cifs_sb = CIFS_SB(inode->i_sb); struct cifs_tcon *tcon = cifs_sb_master_tcon(cifs_sb); + key.uniqueid = cpu_to_le64(cifsi->uniqueid); + key.createtime = cpu_to_le64(cifsi->createtime); + key.type = (inode->i_mode & S_IFMT) >> 12; cifs_fscache_fill_coherency(&cifsi->netfs.inode, &cd); cifsi->netfs.cache = fscache_acquire_cookie(tcon->fscache, 0, - &cifsi->uniqueid, sizeof(cifsi->uniqueid), + &key, sizeof(key), &cd, sizeof(cd), i_size_read(&cifsi->netfs.inode)); if (cifsi->netfs.cache) diff --git a/fs/smb/client/inode.c b/fs/smb/client/inode.c index d28ab0af6049..91b07ef9e25c 100644 --- a/fs/smb/client/inode.c +++ b/fs/smb/client/inode.c @@ -1351,6 +1351,8 @@ cifs_find_inode(struct inode *inode, void *opaque) { struct cifs_fattr *fattr = opaque; + /* [!] The compared values must be the same in struct cifs_fscache_inode_key. */ + /* don't match inode with different uniqueid */ if (CIFS_I(inode)->uniqueid != fattr->cf_uniqueid) return 0;
fscache emits a lot of duplicate cookie warnings with cifs because the index key for the fscache cookies does not include everything that the cifs_find_inode() function does. The latter is used with iget5_locked() to distinguish between inodes in the local inode cache. Fix this by adding the creation time and file type to the fscache cookie key. Additionally, add a couple of comments to note that if one is changed the other must be also. Signed-off-by: David Howells <dhowells@redhat.com> cc: Steve French <sfrench@samba.org> cc: Shyam Prasad N <nspmangalore@gmail.com> cc: Rohith Surabattula <rohiths.msft@gmail.com> cc: Jeff Layton <jlayton@kernel.org> cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org --- fs/smb/client/fscache.c | 16 +++++++++++++++- fs/smb/client/inode.c | 2 ++ 2 files changed, 17 insertions(+), 1 deletion(-)