xfs: fix attr2 vs large data fork assert
authorChristoph Hellwig <hch@infradead.org>
Sat, 19 Nov 2011 17:44:30 +0000 (17:44 +0000)
committerBen Myers <bpm@sgi.com>
Tue, 29 Nov 2011 19:03:12 +0000 (13:03 -0600)
commit4c393a6059f8442a70512a48ce4639b882b6f6ad
treedfff7ce8903ae87a092f3ee2ab213fd06e5a47ec
parent4dd2cb4a28b7ab1f37163a4eba280926a13a8749
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>
fs/xfs/xfs_attr_leaf.c