All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: sandeen@sandeen.net, darrick.wong@oracle.com
Cc: linux-xfs@vger.kernel.org
Subject: [PATCH 5/7] xfs_repair: fix handling of data blocks colliding with existing metadata
Date: Mon, 07 Sep 2020 10:52:28 -0700	[thread overview]
Message-ID: <159950114896.567790.10646736292763230158.stgit@magnolia> (raw)
In-Reply-To: <159950111751.567790.16914248540507629904.stgit@magnolia>

From: Darrick J. Wong <darrick.wong@oracle.com>

Prior to commit a406779bc8d8, any blocks in a data fork extent that
collided with existing blocks would cause the entire data fork extent to
be rejected.  Unfortunately, the patch to add data block sharing support
suppressed checking for any collision, including metadata.  What we
really wanted to do here during a check_dups==1 scan is to is check for
specific collisions and without updating the block mapping data.

So, move the check_dups test after the for-switch construction.  This
re-enables detecting collisions between data fork blocks and a
previously scanned chunk of metadata, and improves the specificity of
the error message that results.

This was found by fuzzing recs[2].free=zeroes in xfs/364, though this
patch alone does not solve all the problems that scenario presents.

Fixes: a406779bc8d8 ("xfs_repair: handle multiple owners of data blocks")
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
---
 repair/dinode.c |   33 +++++++++++----------------------
 1 file changed, 11 insertions(+), 22 deletions(-)


diff --git a/repair/dinode.c b/repair/dinode.c
index 1fe68bd41117..7577b50ffb2b 100644
--- a/repair/dinode.c
+++ b/repair/dinode.c
@@ -476,28 +476,6 @@ _("Fatal error: inode %" PRIu64 " - blkmap_set_ext(): %s\n"
 			locked_agno = agno;
 		}
 
-		if (check_dups) {
-			/*
-			 * if we're just checking the bmap for dups,
-			 * return if we find one, otherwise, continue
-			 * checking each entry without setting the
-			 * block bitmap
-			 */
-			if (!(type == XR_INO_DATA &&
-			    xfs_sb_version_hasreflink(&mp->m_sb)) &&
-			    search_dup_extent(agno, agbno, ebno)) {
-				do_warn(
-_("%s fork in ino %" PRIu64 " claims dup extent, "
-  "off - %" PRIu64 ", start - %" PRIu64 ", cnt %" PRIu64 "\n"),
-					forkname, ino, irec.br_startoff,
-					irec.br_startblock,
-					irec.br_blockcount);
-				goto done;
-			}
-			*tot += irec.br_blockcount;
-			continue;
-		}
-
 		for (b = irec.br_startblock;
 		     agbno < ebno;
 		     b += blen, agbno += blen) {
@@ -554,6 +532,17 @@ _("illegal state %d in block map %" PRIu64 "\n"),
 			}
 		}
 
+		if (check_dups) {
+			/*
+			 * If we're just checking the bmap for dups and we
+			 * didn't find any non-reflink collisions, update our
+			 * inode's block count and move on to the next extent.
+			 * We're not yet updating the block usage information.
+			 */
+			*tot += irec.br_blockcount;
+			continue;
+		}
+
 		/*
 		 * Update the internal extent map only after we've checked
 		 * every block in this extent.  The first time we reject this


  parent reply	other threads:[~2020-09-07 17:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-07 17:51 [PATCH 0/7] xfs_repair: more fuzzer fixes Darrick J. Wong
2020-09-07 17:52 ` [PATCH 1/7] xfs_repair: don't crash on partially sparse inode clusters Darrick J. Wong
2020-09-08 14:43   ` Christoph Hellwig
2020-09-07 17:52 ` [PATCH 2/7] xfs_repair: fix error in process_sf_dir2_fixi8 Darrick J. Wong
2020-09-08 14:46   ` Christoph Hellwig
2020-09-07 17:52 ` [PATCH 3/7] xfs_repair: junk corrupt xattr root blocks Darrick J. Wong
2020-09-08 14:47   ` Christoph Hellwig
2020-09-07 17:52 ` [PATCH 4/7] xfs_repair: complain about unwritten extents when they're not appropriate Darrick J. Wong
2020-09-08 14:51   ` Christoph Hellwig
2020-09-07 17:52 ` Darrick J. Wong [this message]
2020-09-08 14:52   ` [PATCH 5/7] xfs_repair: fix handling of data blocks colliding with existing metadata Christoph Hellwig
2020-09-07 17:52 ` [PATCH 6/7] xfs_repair: throw away totally bad clusters Darrick J. Wong
2020-09-08 15:15   ` Christoph Hellwig
2020-09-29 15:34     ` Darrick J. Wong
2020-09-29 15:35   ` [PATCH v2 " Darrick J. Wong
2020-09-30  6:17     ` Christoph Hellwig
2020-09-07 17:52 ` [PATCH 7/7] xfs_repair: use libxfs_verify_rtbno to verify rt extents Darrick J. Wong
2020-09-08 14:54   ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=159950114896.567790.10646736292763230158.stgit@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.