diff options
author | Darrick J. Wong <djwong@kernel.org> | 2022-10-27 09:48:59 -0700 |
---|---|---|
committer | Darrick J. Wong <djwong@kernel.org> | 2022-10-31 08:58:21 -0700 |
commit | f1fdc8207840672a46f26414f2c989ec078a153b (patch) | |
tree | 9700ba9c03974bec6e7c867664257f89b89065a8 /arch/arm64/kvm/trace.h | |
parent | f62ac3e0ac33d366fe81e194fee81de9be2cd886 (diff) | |
download | linux-f1fdc8207840672a46f26414f2c989ec078a153b.tar.gz linux-f1fdc8207840672a46f26414f2c989ec078a153b.tar.bz2 linux-f1fdc8207840672a46f26414f2c989ec078a153b.zip |
xfs: fix agblocks check in the cow leftover recovery function
As we've seen, refcount records use the upper bit of the rc_startblock
field to ensure that all the refcount records are at the right side of
the refcount btree. This works because an AG is never allowed to have
more than (1U << 31) blocks in it. If we ever encounter a filesystem
claiming to have that many blocks, we absolutely do not want reflink
touching it at all.
However, this test at the start of xfs_refcount_recover_cow_leftovers is
slightly incorrect -- it /should/ be checking that agblocks isn't larger
than the XFS_MAX_CRC_AG_BLOCKS constant, and it should check that the
constant is never large enough to conflict with that CoW flag.
Note that the V5 superblock verifier has not historically rejected
filesystems where agblocks >= XFS_MAX_CRC_AG_BLOCKS, which is why this
ended up in the COW recovery routine.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Diffstat (limited to 'arch/arm64/kvm/trace.h')
0 files changed, 0 insertions, 0 deletions