summaryrefslogtreecommitdiffstats
path: root/fs/xfs/xfs_bmap.c
diff options
context:
space:
mode:
authorChristoph Hellwig <hch@infradead.org>2011-11-19 17:44:30 +0000
committerBen Myers <bpm@sgi.com>2011-11-29 13:03:12 -0600
commit4c393a6059f8442a70512a48ce4639b882b6f6ad (patch)
treedfff7ce8903ae87a092f3ee2ab213fd06e5a47ec /fs/xfs/xfs_bmap.c
parent4dd2cb4a28b7ab1f37163a4eba280926a13a8749 (diff)
downloadlinux-4c393a6059f8442a70512a48ce4639b882b6f6ad.tar.gz
linux-4c393a6059f8442a70512a48ce4639b882b6f6ad.tar.bz2
linux-4c393a6059f8442a70512a48ce4639b882b6f6ad.zip
xfs: fix attr2 vs large data fork assert
With Dmitry fsstress updates I've seen very reproducible crashes in xfs_attr_shortform_remove because xfs_attr_shortform_bytesfit claims that the attributes would not fit inline into the inode after removing an attribute. It turns out that we were operating on an inode with lots of delalloc extents, and thus an if_bytes values for the data fork that is larger than biggest possible on-disk storage for it which utterly confuses the code near the end of xfs_attr_shortform_bytesfit. Fix this by always allowing the current attribute fork, like we already do for the attr1 format, given that delalloc conversion will take care for moving either the data or attribute area out of line if it doesn't fit at that point - or making the point moot by merging extents at this point. Also document the function better, and clean up some loose bits. Reviewed-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Ben Myers <bpm@sgi.com>
Diffstat (limited to 'fs/xfs/xfs_bmap.c')
0 files changed, 0 insertions, 0 deletions