| To: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH 4/5] xfs: use xfs_ilock_map_shared in xfs_attr_get |
| From: | Dave Chinner <david@xxxxxxxxxxxxx> |
| Date: | Fri, 6 Dec 2013 08:17:38 +1100 |
| Cc: | xfs@xxxxxxxxxxx |
| Delivered-to: | xfs@xxxxxxxxxxx |
| In-reply-to: | <20131205211055.GA3209@xxxxxxxxxxxxx> |
| References: | <20131205155830.620826868@xxxxxxxxxxxxxxxxxxxxxx> <20131205155951.679310054@xxxxxxxxxxxxxxxxxxxxxx> <20131205205910.GD29897@dastard> <20131205210159.GA30318@xxxxxxxxxxxxx> <20131205210557.GF29897@dastard> <20131205211055.GA3209@xxxxxxxxxxxxx> |
| User-agent: | Mutt/1.5.21 (2010-09-15) |
On Thu, Dec 05, 2013 at 01:10:55PM -0800, Christoph Hellwig wrote: > On Fri, Dec 06, 2013 at 08:05:57AM +1100, Dave Chinner wrote: > > > Haven't really done an in-depth audit, mostly just looking at > > > where the asserts kick in.. > > > > Right - I just did a scan with cscope on the users of > > XFS_ILOCK_SHARED, and those two were the only ones that stuck out > > that weren't handled correctly.... > > With MAXPATHLEN at 1024 a symlink is at max 2 extents and thus never in > btree format, so I don't think we'll need it in readlink. The attr > cases look real, though. True, because the data fork will always have space for 3 extents (#define MINDBTPTRS 3) and so it won't go out of line regardless of the attribute fork. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 5/5] xfs: assert that we hold the ilock for extent map access, Dave Chinner |
|---|---|
| Next by Date: | Re: [PATCH 5/5] xfs: assert that we hold the ilock for extent map access, Christoph Hellwig |
| Previous by Thread: | Re: [PATCH 4/5] xfs: use xfs_ilock_map_shared in xfs_attr_get, Christoph Hellwig |
| Next by Thread: | [PATCH 1/5] xfs: take the ilock around xfs_bmapi_read in xfs_zero_remaining_bytes, Christoph Hellwig |
| Indexes: | [Date] [Thread] [Top] [All Lists] |