On Mon, Mar 08, 2021 at 05:20:17PM +0800, Qu Wenruo wrote:
> [BUG]
> Btrfs fails at generic/091 test case, with the following output:
>
> fsx -N 10000 -o 128000 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -W
> mapped writes DISABLED
> Seed set to 1
> main: filesystem does not support fallocate mode FALLOC_FL_COLLAPSE_RANGE,
> disabling!
> main: filesystem does not support fallocate mode FALLOC_FL_INSERT_RANGE,
> disabling!
> skipping zero size read
> truncating to largest ever: 0xe400
> copying to largest ever: 0x1f400
> cloning to largest ever: 0x70000
> cloning to largest ever: 0x77000
> fallocating to largest ever: 0x7a120
> Mapped Read: non-zero data past EOF (0x3a7ff) page offset 0x800 is 0xf2e1
> <<<
> ...
>
> [CAUSE]
> In commit c28ea613fafa ("btrfs: subpage: fix the false data csum mismatch
> error")
> end_bio_extent_readpage() changes to only zero the range inside the bvec
> for incoming subpage support.
>
> But that commit is using incorrect offset to calculate the start.
>
> For subpage, we can have a case that the whole bvec is beyond isize,
> thus we need to calculate the correct offset.
>
> But the offending commit is using @end (bvec end), other than @start
> (bvec start) to calculate the start offset.
>
> This means, we only zero the last byte of the bvec, not from the isize.
> This stupid bug makes the range beyond isize is not properly zeroed, and
> failed above test.
>
> [FIX]
> Use correct @start to calculate the range start.
>
> Reported-by: kernel test robot <oliver.s...@intel.com>
> Signed-off-by: Qu Wenruo <w...@suse.com>
Added to misc-next, thanks.
