On Thu, Apr 19, 2018 at 01:32:24AM -0700, Christoph Hellwig wrote: > On Tue, Apr 17, 2018 at 07:39:39PM -0700, Darrick J. Wong wrote: > > From: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > > > > Create a new QMOPT flag to signal that we've already locked the quota > > inode. This will be used by the quota scrub code refactoring to avoid > > dropping the quota ip lock during scrub. The flag is incompatible with > > the DQALLOC flag because dquot allocation creates a transaction, and we > > shouldn't be doing that with the ILOCK held. > > Locked flag are always a sign for code smell. And this already is > pretty smelly code before that flag is added. I think someone (i.e. > either you or me :)) needs to do a major refactoring here first. Bleh... ok, I marched through that swamp and refactored all that goopy dqget crud into a ton of smaller helper functions that only do one thing, killed off QMOPT_NEXT, and renamed DQALLOC to make it obvious it's for dqget only. So now we have... xfs_qm_dqget (get dquot based on id/type, can take XFS_DQGET_DQALLOC to allocate if not present) xfs_qm_dqget_inode (get dquot based on inode/type, contains all the locking and looping mess to one function, can take _DQALLOC) xfs_qm_dqget_next (get this or the next higher dquot, no DQALLOC allowed here, contain all the NEXT looping mess to this function) xfs_qm_dqread (read dquot from disk and return incore dquot, do not check in radix tree, no longer takes DQALLOC) xfs_qm_dqiterate (iterate all the dquots for the given quota type) I also cleaned out a bunch of unnecessary parameters and other junk, and refactored mount time quotacheck so that it doesn't need to ILOCK_EXCL every inode in the system. In theory that should be fine because we only needed ILOCK_EXCL to make sure nobody can chown/chproj the inode on us, which shouldn't be happening during mount. As a bonus I realized that scrub and repair don't actually need to maintain the ilock once they're done fixing all of the things that can cause dqget to fail, so the ILOCKED flag goes away entirely. Will have a revised megaseries out on the list ideally some time before LSF starts... though it did add another 12 patches to the review queue. :P --D > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
