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

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(-)

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