Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> > We're seeing cases where fscache is reporting cookie collisions that appears
> > to be due to ->evict_inode() running parallel with a new inode for the same
> > filesystem object getting set up.
>
> Huh? Details, please. What we are guaranteed is that iget{,5}_locked() et.al.
> on the same object will either prevent the call of ->evict_inode() (if they
> manage to grab the sucker before I_FREEING is set) or will wait until after
> ->evict_inode() returns.
See the trace from Luis in:
https://lore.kernel.org/linux-fsdevel/87fsysyxh9.fsf@xxxxxxx/
It appears that process 20591 manages to set up a new inode that has the same
key parameters as the one process 20585 is tearing down.
0000000097476aaa is the cookie pointer used by the old inode.
0000000011fa06b1 is the cookie pointer used by the new inode.
000000003080d900 is the cookie pointer for the parent superblock.
The fscache_acquire traceline emission is caused by one of:
(*) v9fs_qid_iget() or v9fs_qid_iget_dotl() calling
v9fs_cache_inode_get_cookie().
(*) v9fs_file_open*(O_RDONLY) or v9fs_vfs_atomic_open*(O_RDONLY) calling
v9fs_cache_inode_set_cookie().
(*) v9fs_cache_inode_reset_cookie(), which appears unused.
The fscache_relinquish traceline emission is caused by one of:
(*) v9fs_file_open(O_RDWR/O_WRONLY) or v9fs_vfs_atomic_open(O_RDWR/O_WRONLY)
calling v9fs_cache_inode_set_cookie().
(*) v9fs_evict_inode() calling v9fs_cache_inode_put_cookie().
(*) v9fs_cache_inode_reset_cookie(), which appears unused.
>From the backtrace in:
https://lore.kernel.org/linux-fsdevel/87czu45gcs.fsf@xxxxxxx/
the acquisition is being triggered in v9fs_vfs_atomic_open_dotl(), so it seems
v9fs_qid_iget_dotl() already happened - which *should* have created the
cookie.
So it seems more complicated than I thought.
David
