I think that I'm going to have to store the inode index key in the fscache_cookie struct so that I can deal with some apparent circumstances where a filesystem appears to contain two active inodes that refer to the same server object. This seems to have happened with NFS and CIFS. You get something that looks like: CacheFiles: Error: Unexpected object collision CacheFiles: object: OBJ1c CacheFiles: objstate=LOOK_UP_OBJECT fl=8 wbusy=2 ev=0[0] CacheFiles: ops=0 inp=0 exc=0 CacheFiles: parent=ffff8800d9d96140 CacheFiles: cookie=ffff8800d03bd230 [pr=ffff8800cc1ca000 nd=ffff8800cb4a2490 fl=27] CacheFiles: key=[8] '40a0080501090000' CacheFiles: xobject: OBJ1a CacheFiles: xobjstate=WAIT_FOR_CMD fl=38 wbusy=0 ev=0[6d] CacheFiles: xops=0 inp=0 exc=0 CacheFiles: xparent=ffff8800d9d96140 CacheFiles: xcookie=ffff8800d03bd190 [pr=ffff8800cc1ca000 nd=ffff8800cb4aad00 fl=22] CacheFiles: xkey=[8] '40a0080501090000' ------------[ cut here ]------------ kernel BUG at fs/cachefiles/namei.c:196! Both objects appear to be valid, but key and xkey are the same. What I propose to do is to take a copy of the index key and store it in the cookie in fscache_acquire_cookie() and keep all of the cookies in an associative array. Then when fscache_acquire_cookie() is called, it checks the index key it obtained against the associative array and rejects attempts to use a duplicate key right up front rather down in the bowels of the cache implementation where it's much harder to recover. Now, what I was thinking of is to create 16 bytes of space in the cookie and to use a flag to indicate whether this contains the index key or a pointer to the index key. AFS and Ceph can both fit their inode keys within this, but NFS's inode index keys are NFS FH's and can be much larger. Would it make sense to make this space larger in the hope of fitting in NFS FH's? David -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cachefs
