[PATCH] btrfs: fix wrong offset to zero out range beyond isize

[PATCH] btrfs: fix wrong offset to zero out range beyond isize

[Qu Wenruo]

[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.sang@intel.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
Sorry, I didn't do the full test for the offending patch, thinking such
small change, which only affects read after isize, shoudn't cause much
problem.

All my fault.
---
 fs/btrfs/extent_io.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 4671c99d468d..f3d7be975c3a 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -3020,7 +3020,7 @@ static void end_bio_extent_readpage(struct bio *bio)
 			 */
 			if (page->index == end_index && i_size <= end) {
 				u32 zero_start = max(offset_in_page(i_size),
-						     offset_in_page(end));
+						     offset_in_page(start));
 
 				zero_user_segment(page, zero_start,
 						  offset_in_page(end) + 1);
-- 
2.30.1

Re: [PATCH] btrfs: fix wrong offset to zero out range beyond isize

[David Sterba]

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.sang@intel.com>
> Signed-off-by: Qu Wenruo <wqu@suse.com>

Added to misc-next, thanks.