Review: Fix dbflush panic in xfs_qm_sync

The recent behaviour layer removal dropped the check for quotas that have been requested at mount time but have subsequently been turned off. This results in a panic when accessing m_quotainfo which has been freed.

This patch adds the check originally made by xfs_qm_syncall() to xfs_qm_sync()

@@ -1007,6 +1007,9 @@ xfs_qm_sync(
 	boolean_t	nowait;
 	int		error;
 
+	if (! XFS_IS_QUOTA_ON(mp))
+		return 0;
+
 	restarts = 0;
 	/*
 	 * We won't block unless we are asked to.

Could mp->m_quotainfo become NULL after this check but before we lock the list with xfs_qm_mplist_lock()? There doesn't seem to be any locking to protect changes to this field?

Possible - in theory. Likely - no. We do the same unlocked check in a few places...

Cheers,

Dave.

Dave Chinner
Principal Engineer
SGI Australian Software Group

The mplist lock doesnt prevent the quotainfo going away while its held. It's just guarding a hashlist that lives in quotainfo structure. So none of this code prevents a quotaoff race.

In the short term this change restores the original checks. But in the longer term we should review the locking in the quota system, possibly adding a quotaoff lock to xfs_mount_t.

Don

Hmm. We do the same check just a few lines below, but inbetween we access ->m_quotainfo to take the lock. I was under the impression that's the only safe way to check anyway, but ->m_quotainfo might not actually be present. It might me better to move the lock into xfs_mount directly, but it's embedded into a xfs_dqhash and there's some complex mess with gazillions of macros around it.

So I suspect restoring it to the original state might be good enough.