diff options
| author | Darrick J. Wong <djwong@kernel.org> | 2024-12-02 21:57:26 +0300 |
|---|---|---|
| committer | Darrick J. Wong <djwong@kernel.org> | 2024-12-13 04:45:09 +0300 |
| commit | bd27c7bcdca25ce8067ebb94ded6ac1bd7b47317 (patch) | |
| tree | 5d7a97976255a4ccac2d357540b0d5d0612caf20 /fs/xfs/libxfs/xfs_btree.c | |
| parent | e1d8602b6cfb757952827d11c7d26f2a1714fe82 (diff) | |
| download | linux-bd27c7bcdca25ce8067ebb94ded6ac1bd7b47317.tar.xz | |
xfs: return a 64-bit block count from xfs_btree_count_blocks
With the nrext64 feature enabled, it's possible for a data fork to have
2^48 extent mappings. Even with a 64k fsblock size, that maps out to
a bmbt containing more than 2^32 blocks. Therefore, this predicate must
return a u64 count to avoid an integer wraparound that will cause scrub
to do the wrong thing.
It's unlikely that any such filesystem currently exists, because the
incore bmbt would consume more than 64GB of kernel memory on its own,
and so far nobody except me has driven a filesystem that far, judging
from the lack of complaints.
Cc: <stable@vger.kernel.org> # v5.19
Fixes: df9ad5cc7a5240 ("xfs: Introduce macros to represent new maximum extent counts for data/attr forks")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Diffstat (limited to 'fs/xfs/libxfs/xfs_btree.c')
| -rw-r--r-- | fs/xfs/libxfs/xfs_btree.c | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/fs/xfs/libxfs/xfs_btree.c b/fs/xfs/libxfs/xfs_btree.c index 2b5fc5fd1643..c748866ef923 100644 --- a/fs/xfs/libxfs/xfs_btree.c +++ b/fs/xfs/libxfs/xfs_btree.c @@ -5144,7 +5144,7 @@ xfs_btree_count_blocks_helper( int level, void *data) { - xfs_extlen_t *blocks = data; + xfs_filblks_t *blocks = data; (*blocks)++; return 0; @@ -5154,7 +5154,7 @@ xfs_btree_count_blocks_helper( int xfs_btree_count_blocks( struct xfs_btree_cur *cur, - xfs_extlen_t *blocks) + xfs_filblks_t *blocks) { *blocks = 0; return xfs_btree_visit_blocks(cur, xfs_btree_count_blocks_helper, |