| To: | Dave Chinner <david@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH 5/5] xfs: assert that we hold the ilock for extent map access |
| From: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
| Date: | Thu, 5 Dec 2013 13:22:19 -0800 |
| Cc: | Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx |
| Delivered-to: | xfs@xxxxxxxxxxx |
| In-reply-to: | <20131205211047.GG29897@dastard> |
| References: | <20131205155830.620826868@xxxxxxxxxxxxxxxxxxxxxx> <20131205155951.874279041@xxxxxxxxxxxxxxxxxxxxxx> <20131205211047.GG29897@dastard> |
| User-agent: | Mutt/1.5.21 (2010-09-15) |
On Fri, Dec 06, 2013 at 08:10:47AM +1100, Dave Chinner wrote: > Looks good, but can we add an assert to xfs_bunmapi() at the same > time just to cover all the public bmapi interfaces with locking > requirements? Sure, will do. Btw, I got another idea to sort this mess out a bit better: - add a new XFS_ILOCK_BMAP flag, and fold the bmap locking magic into xfs_ilock. - because the flag is now passed down we can assert that it is passed in xfs_bmapi_read and friends even if the extent list is already read in and thus improve coverage. The downside is another two branches in the common ilock code path. |
| Previous by Date: | Re: [PATCH 4/5] xfs: use xfs_ilock_map_shared in xfs_attr_get, Dave Chinner |
|---|---|
| Next by Date: | Re: [PATCH 5/5] xfs: assert that we hold the ilock for extent map access, Dave Chinner |
| Previous by Thread: | Re: [PATCH 5/5] xfs: assert that we hold the ilock for extent map access, Dave Chinner |
| Next by Thread: | Re: [PATCH 5/5] xfs: assert that we hold the ilock for extent map access, Dave Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |