summaryrefslogtreecommitdiffstats
path: root/fs/xfs/scrub/dabtree.c
diff options
context:
space:
mode:
authorDarrick J. Wong <darrick.wong@oracle.com>2017-11-08 21:21:05 +0100
committerDarrick J. Wong <darrick.wong@oracle.com>2017-11-09 18:10:45 +0100
commit4da4b10b5bde05d5b666405c74362a93da4b5ec4 (patch)
treec5d972f8e3ed28b3eaaa71c9c3cff4fdf745d070 /fs/xfs/scrub/dabtree.c
parentxfs: fix btree scrub deref check (diff)
downloadlinux-4da4b10b5bde05d5b666405c74362a93da4b5ec4.tar.xz
linux-4da4b10b5bde05d5b666405c74362a93da4b5ec4.zip
xfs: only check da node header padding on v5 filesystems
It turns out that we only started zeroing a new da btree node's block header on v5 filesystems. Prior to that, we just wouldn't set anything at all, which means that the pad field never got set and would retain whatever happened to be in memory. Therefore, we can only check the pad for zeroness on v5 filesystems. shared/006 on a v4 filesystem exposes this scrub bug. Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Dave Chinner <dchinner@redhat.com>
Diffstat (limited to 'fs/xfs/scrub/dabtree.c')
-rw-r--r--fs/xfs/scrub/dabtree.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/fs/xfs/scrub/dabtree.c b/fs/xfs/scrub/dabtree.c
index 4c9839c40163..d94edd93cba8 100644
--- a/fs/xfs/scrub/dabtree.c
+++ b/fs/xfs/scrub/dabtree.c
@@ -378,7 +378,8 @@ xfs_scrub_da_btree_block(
blk->magic = be16_to_cpu(hdr3->hdr.magic);
pmaxrecs = &ds->maxrecs[level];
- if (hdr3->hdr.pad != cpu_to_be16(0))
+ /* We only started zeroing the header on v5 filesystems. */
+ if (xfs_sb_version_hascrc(&ds->sc->mp->m_sb) && hdr3->hdr.pad)
xfs_scrub_da_set_corrupt(ds, level);
/* Check the owner. */