On Tue, Jan 18, 2022 at 03:12:53PM +1100, Dave Chinner wrote: > No, that just creates a black hole where the VFS inode has been > destroyed but the XFS inode cache doesn't know it's been trashed. > Hence setting XFS_IRECLAIMABLE needs to remain in the during > ->destroy_inode, otherwise the ->lookup side of the cache will think > that are currently still in use by the VFS and hand them straight > back out without going through the inode recycling code. > > i.e. XFS_IRECLAIMABLE is the flag that tells xfs_iget() that the VFS > part of the inode has been torn down, and that it must go back > through VFS re-initialisation before it can be re-instantiated as a > VFS inode. OK... > It would also mean that the inode will need to go through two RCU > grace periods before it gets reclaimed, because XFS uses RCU > protected inode cache lookups internally (e.g. for clustering dirty > inode writeback) and so freeing the inode from the internal > XFS inode cache requires RCU freeing... Wait a minute. Where is that RCU delay of yours, relative to xfs_vn_unlink() and xfs_vn_rename() (for target)? And where does it happen in case of e.g. open() + unlink() + close()?
