| Message ID | 20210308092017.81059-1-wqu@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | btrfs: fix wrong offset to zero out range beyond isize | expand |
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.
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);
[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(-)