linux-kernel - Re: [PATCH 01/26] cifs: Fix duplicate fscache cookie warnings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <39de1e2ac2ae6a535e23faccd304d7c5459054a2.camel@kernel.org>
Date: Mon, 15 Apr 2024 07:25:29 -0400
From: Jeff Layton <jlayton@...nel.org>
To: David Howells <dhowells@...hat.com>, Christian Brauner
	 <christian@...uner.io>, Gao Xiang <hsiangkao@...ux.alibaba.com>, Dominique
	Martinet <asmadeus@...ewreck.org>
Cc: Matthew Wilcox <willy@...radead.org>, Steve French <smfrench@...il.com>,
  Marc Dionne <marc.dionne@...istor.com>, Paulo Alcantara
 <pc@...guebit.com>, Shyam Prasad N <sprasad@...rosoft.com>, Tom Talpey
 <tom@...pey.com>, Eric Van Hensbergen <ericvh@...nel.org>, Ilya Dryomov
 <idryomov@...il.com>, netfs@...ts.linux.dev,  linux-cachefs@...hat.com,
 linux-afs@...ts.infradead.org,  linux-cifs@...r.kernel.org,
 linux-nfs@...r.kernel.org,  ceph-devel@...r.kernel.org,
 v9fs@...ts.linux.dev, linux-erofs@...ts.ozlabs.org, 
 linux-fsdevel@...r.kernel.org, linux-mm@...ck.org, netdev@...r.kernel.org, 
 linux-kernel@...r.kernel.org, Steve French <sfrench@...ba.org>, Shyam
 Prasad N <nspmangalore@...il.com>, Rohith Surabattula
 <rohiths.msft@...il.com>
Subject: Re: [PATCH 01/26] cifs: Fix duplicate fscache cookie warnings

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@...hat.com>
> cc: Steve French <sfrench@...ba.org>
> cc: Shyam Prasad N <nspmangalore@...il.com>
> cc: Rohith Surabattula <rohiths.msft@...il.com>
> cc: Jeff Layton <jlayton@...nel.org>
> cc: linux-cifs@...r.kernel.org
> cc: netfs@...ts.linux.dev
> cc: linux-fsdevel@...r.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@...nel.org>