summaryrefslogtreecommitdiffstats
path: root/arch/arm64/kvm/trace.h
diff options
context:
space:
mode:
authorDarrick J. Wong <djwong@kernel.org>2022-10-27 09:48:59 -0700
committerDarrick J. Wong <djwong@kernel.org>2022-10-31 08:58:21 -0700
commitf1fdc8207840672a46f26414f2c989ec078a153b (patch)
tree9700ba9c03974bec6e7c867664257f89b89065a8 /arch/arm64/kvm/trace.h
parentf62ac3e0ac33d366fe81e194fee81de9be2cd886 (diff)
downloadlinux-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