diff options
author | Dave Chinner <dchinner@redhat.com> | 2023-03-05 15:13:23 -0800 |
---|---|---|
committer | Darrick J. Wong <djwong@kernel.org> | 2023-03-05 15:13:23 -0800 |
commit | 8ac5b996bf5199f15b7687ceae989f8b2a410dda (patch) | |
tree | 0fcb86b1e5b0b6e860e6b557707da35e4a4037a2 /fs/netfs | |
parent | 0c7273e494dd5121e20e160cb2f047a593ee14a8 (diff) | |
download | linux-stable-8ac5b996bf5199f15b7687ceae989f8b2a410dda.tar.gz linux-stable-8ac5b996bf5199f15b7687ceae989f8b2a410dda.tar.bz2 linux-stable-8ac5b996bf5199f15b7687ceae989f8b2a410dda.zip |
xfs: fix off-by-one-block in xfs_discard_folio()
The recent writeback corruption fixes changed the code in
xfs_discard_folio() to calculate a byte range to for punching
delalloc extents. A mistake was made in using round_up(pos) for the
end offset, because when pos points at the first byte of a block, it
does not get rounded up to point to the end byte of the block. hence
the punch range is short, and this leads to unexpected behaviour in
certain cases in xfs_bmap_punch_delalloc_range.
e.g. pos = 0 means we call xfs_bmap_punch_delalloc_range(0,0), so
there is no previous extent and it rounds up the punch to the end of
the delalloc extent it found at offset 0, not the end of the range
given to xfs_bmap_punch_delalloc_range().
Fix this by handling the zero block offset case correctly.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=217030
Link: https://lore.kernel.org/linux-xfs/Y+vOfaxIWX1c%2Fyy9@bfoster/
Fixes: 7348b322332d ("xfs: xfs_bmap_punch_delalloc_range() should take a byte range")
Reported-by: Pengfei Xu <pengfei.xu@intel.com>
Found-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Diffstat (limited to 'fs/netfs')
0 files changed, 0 insertions, 0 deletions