Re: [PATCH 2/5] xfs: fix memory corruption during remote attr value buffer invalidation

[Christoph Hellwig <hch@infradead.org>]

> While running generic/103, I observed what looks like memory corruption
> and (with slub debugging turned on) a slub redzone warning on i386 when
> inactivating an inode with a 64k remote attr value.
> 
> On a v5 filesystem, maximally sized remote attr values require one block
> more than 64k worth of space to hold both the remote attribute value
> header (64 bytes).  On a 4k block filesystem this results in a 68k
> buffer; on a 64k block filesystem, this would be a 128k buffer.  Note
> that even though we'll never use more than 65,600 bytes of this buffer,
> XFS_MAX_BLOCKSIZE is 64k.
> 
> This is a problem because the definition of struct xfs_buf_log_format
> allows for XFS_MAX_BLOCKSIZE worth of dirty bitmap (64k).  On i386 when we
> invalidate a remote attribute, xfs_trans_binval zeroes all 68k worth of
> the dirty map, writing right off the end of the log item and corrupting
> memory.  We've gotten away with this on x86_64 for years because the
> compiler inserts a u32 padding on the end of struct xfs_buf_log_format.
> 
> Fortunately for us, remote attribute values are written to disk with
> xfs_bwrite(), which is to say that they are not logged.  Fix the problem
> by removing all places where we could end up creating a buffer log item
> for a remote attribute value and leave a note explaining why.

I think this changelog needs an explanation why using
xfs_attr_rmtval_stale which just trylock and checks if the buffers are
in core only in xfs_attr3_leaf_freextent is fine.  And while the incore
part looks sane to me, I think the trylock is wrong and we need to pass
the locking flag to xfs_attr_rmtval_stale.