xfs
[Top] [All Lists]

Re: Review: Fix dbflush panic in xfs_qm_sync

To: David Chinner <dgc@xxxxxxx>
Subject: Re: Review: Fix dbflush panic in xfs_qm_sync
From: Donald Douwsma <donaldd@xxxxxxx>
Date: Wed, 17 Oct 2007 11:54:28 +1000
Cc: Lachlan McIlroy <lachlan@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <20071016060726.GR995458@xxxxxxx>
References: <4713F7D3.2090201@xxxxxxx> <4714498A.8090902@xxxxxxx> <20071016060726.GR995458@xxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
David Chinner wrote:
On Tue, Oct 16, 2007 at 03:18:02PM +1000, Lachlan McIlroy wrote:
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...


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



<Prev in Thread] Current Thread [Next in Thread>