summaryrefslogtreecommitdiffstats
path: root/fs/xfs/scrub/fscounters.c
diff options
context:
space:
mode:
authorDarrick J. Wong <djwong@kernel.org>2023-10-16 18:21:38 +0200
committerDarrick J. Wong <djwong@kernel.org>2023-10-18 01:24:22 +0200
commitf6a2dae2a1f52ea23f649c02615d073beba4cc35 (patch)
tree89f111ddf41ba3df3b8798589051f18e00c6b910 /fs/xfs/scrub/fscounters.c
parentxfs: fix units conversion error in xfs_bmap_del_extent_delay (diff)
downloadlinux-f6a2dae2a1f52ea23f649c02615d073beba4cc35.tar.xz
linux-f6a2dae2a1f52ea23f649c02615d073beba4cc35.zip
xfs: make sure maxlen is still congruent with prod when rounding down
In commit 2a6ca4baed62, we tried to fix an overflow problem in the realtime allocator that was caused by an overly large maxlen value causing xfs_rtcheck_range to run off the end of the realtime bitmap. Unfortunately, there is a subtle bug here -- maxlen (and minlen) both have to be aligned with @prod, but @prod can be larger than 1 if the user has set an extent size hint on the file, and that extent size hint is larger than the realtime extent size. If the rt free space extents are not aligned to this file's extszhint because other files without extent size hints allocated space (or the number of rt extents is similarly not aligned), then it's possible that maxlen after clamping to sb_rextents will no longer be aligned to prod. The allocation will succeed just fine, but we still trip the assertion. Fix the problem by reducing maxlen by any misalignment with prod. While we're at it, split the assertions into two so that we can tell which value had the bad alignment. Fixes: 2a6ca4baed62 ("xfs: make sure the rt allocator doesn't run off the end") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Diffstat (limited to 'fs/xfs/scrub/fscounters.c')
0 files changed, 0 insertions, 0 deletions