[Top] [All Lists]

Re: [PATCH 4/5] xfs: use xfs_ilock_map_shared in xfs_attr_get

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.


Dave Chinner

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