On Tue, Mar 30, 2021 at 11:44:07AM +1100, Dave Chinner wrote: > On Thu, Mar 25, 2021 at 05:21:18PM -0700, Darrick J. Wong wrote: > > From: Christoph Hellwig <hch@xxxxxx> > > > > Using xfs_inode_walk in xfs_qm_dqrele_all_inodes is complete overkill, > > given that function simplify wants to iterate all live inodes known > > to the VFS. Just iterate over the s_inodes list. > > I'm not sure that assertion is true. We attach dquots during inode > inactivation after the VFS has removed the inode from the s_inodes > list and evicted the inode. Hence there is a window between the > inode being removed from the sb->s_inodes lists and it being marked > XFS_IRECLAIMABLE where we can attach dquots to the inode. > > Indeed, an inode marked XFS_IRECLAIMABLE that has gone through > evict -> destroy -> inactive -> nlink != 0 -> xfs_free_ eofblocks() > can have referenced dquots attached to it and require dqrele() to be > called to release them. Why do the dquots need to remain attached after destroy_inode? We can easily reattach them during inactivation (v3 did this), and I don't know why an inode needs dquots once we're through making metadata updates. > Hence I think that xfs_qm_dqrele_all_inodes() is broken if all it is > doing is walking vfs referenced inodes, because it doesn't actually > release the dquots attached to reclaimable inodes. If this did > actually release all dquots, then there wouldn't be a need for the > xfs_qm_dqdetach() call in xfs_reclaim_inode() just before it's > handed to RCU to be freed.... Why does it work now, then? The current code /also/ leaves the dquots attached to reclaimable inodes, and the quotaoff scan ignores IRECLAIMABLE inodes. Has it simply been the case that the dqpurge spins until reclaim runs, and reclaim gets run quickly enough (or quotaoff runs infrequently enough) that nobody's complained? --D > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx
