diff mbox series

[01/26] cifs: Fix duplicate fscache cookie warnings

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

Commit Message

David Howells March 28, 2024, 4:33 p.m. UTC
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(-)

Comments

Jeff Layton April 15, 2024, 11:25 a.m. UTC | #1
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>
David Howells April 15, 2024, 1:03 p.m. UTC | #2
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 April 15, 2024, 10:51 p.m. UTC | #3
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
>
David Howells April 16, 2024, 10:40 p.m. UTC | #4
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 mbox series

Patch

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;