| 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> |
|---|---|---|
| ||
| Previous by Date: | (no subject), Niv Sardi-Altivanik |
|---|---|
| Next by Date: | Review: Make xfs_bulkstat() to report unlinked but referenced inodes, Vlad Apostolov |
| Previous by Thread: | Re: Review: Fix dbflush panic in xfs_qm_sync, David Chinner |
| Next by Thread: | Re: Review: Fix dbflush panic in xfs_qm_sync, Christoph Hellwig |
| Indexes: | [Date] [Thread] [Top] [All Lists] |