Re: [PATCH 5.4, 5.10] btrfs: tree-checker: do not error out if extent ref hash doesn't match

[Sasha Levin <sashal@kernel.org>]

On Fri, Jun 04, 2021 at 05:53:04PM +0200, David Sterba wrote:
>From: Josef Bacik <josef@toxicpanda.com>
>
>commit 1119a72e223f3073a604f8fccb3a470ccd8a4416 upstream.
>
>The tree checker checks the extent ref hash at read and write time to
>make sure we do not corrupt the file system.  Generally extent
>references go inline, but if we have enough of them we need to make an
>item, which looks like
>
>key.objectid	= <bytenr>
>key.type	= <BTRFS_EXTENT_DATA_REF_KEY|BTRFS_TREE_BLOCK_REF_KEY>
>key.offset	= hash(tree, owner, offset)
>
>However if key.offset collide with an unrelated extent reference we'll
>simply key.offset++ until we get something that doesn't collide.
>Obviously this doesn't match at tree checker time, and thus we error
>while writing out the transaction.  This is relatively easy to
>reproduce, simply do something like the following
>
>  xfs_io -f -c "pwrite 0 1M" file
>  offset=2
>
>  for i in {0..10000}
>  do
>	  xfs_io -c "reflink file 0 ${offset}M 1M" file
>	  offset=$(( offset + 2 ))
>  done
>
>  xfs_io -c "reflink file 0 17999258914816 1M" file
>  xfs_io -c "reflink file 0 35998517829632 1M" file
>  xfs_io -c "reflink file 0 53752752058368 1M" file
>
>  btrfs filesystem sync
>
>And the sync will error out because we'll abort the transaction.  The
>magic values above are used because they generate hash collisions with
>the first file in the main subvol.
>
>The fix for this is to remove the hash value check from tree checker, as
>we have no idea which offset ours should belong to.
>
>Reported-by: Tuomas Lähdekorpi <tuomas.lahdekorpi@gmail.com>
>Fixes: 0785a9aacf9d ("btrfs: tree-checker: Add EXTENT_DATA_REF check")
>CC: stable@vger.kernel.org # 5.4+
>Reviewed-by: Filipe Manana <fdmanana@suse.com>
>Signed-off-by: Josef Bacik <josef@toxicpanda.com>
>Reviewed-by: David Sterba <dsterba@suse.com>
>[ add comment]
>Signed-off-by: David Sterba <dsterba@suse.com>
>---
>
>Generated on 5.4 where it applies cleanly and on 5.10 with line offset
>but otherwise clean.

Queued up, thanks!

-- 
Thanks,
Sasha