[Linux-cachefs] Storing inode index key in fscache_cookie struct

[David Howells]

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