All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: darrick.wong@oracle.com
Cc: linux-xfs@vger.kernel.org, david@fromorbit.com
Subject: [PATCH 1/4] xfs: fix brainos in the refcount scrubber's rmap fragment processor
Date: Mon, 09 Nov 2020 10:17:39 -0800	[thread overview]
Message-ID: <160494585913.772802.17231950418756379430.stgit@magnolia> (raw)
In-Reply-To: <160494585293.772802.13326482733013279072.stgit@magnolia>

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

Fix some serious WTF in the reference count scrubber's rmap fragment
processing.  The code comment says that this loop is supposed to move
all fragment records starting at or before bno onto the worklist, but
there's no obvious reason why nr (the number of items added) should
increment starting from 1, and breaking the loop when we've added the
target number seems dubious since we could have more rmap fragments that
should have been added to the worklist.

This seems to manifest in xfs/411 when adding one to the refcount field.

Fixes: dbde19da9637 ("xfs: cross-reference the rmapbt data with the refcountbt")
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
---
 fs/xfs/scrub/refcount.c |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)


diff --git a/fs/xfs/scrub/refcount.c b/fs/xfs/scrub/refcount.c
index beaeb6fa3119..dd672e6bbc75 100644
--- a/fs/xfs/scrub/refcount.c
+++ b/fs/xfs/scrub/refcount.c
@@ -170,7 +170,6 @@ xchk_refcountbt_process_rmap_fragments(
 	 */
 	INIT_LIST_HEAD(&worklist);
 	rbno = NULLAGBLOCK;
-	nr = 1;
 
 	/* Make sure the fragments actually /are/ in agbno order. */
 	bno = 0;
@@ -184,15 +183,14 @@ xchk_refcountbt_process_rmap_fragments(
 	 * Find all the rmaps that start at or before the refc extent,
 	 * and put them on the worklist.
 	 */
+	nr = 0;
 	list_for_each_entry_safe(frag, n, &refchk->fragments, list) {
-		if (frag->rm.rm_startblock > refchk->bno)
-			goto done;
+		if (frag->rm.rm_startblock > refchk->bno || nr > target_nr)
+			break;
 		bno = frag->rm.rm_startblock + frag->rm.rm_blockcount;
 		if (bno < rbno)
 			rbno = bno;
 		list_move_tail(&frag->list, &worklist);
-		if (nr == target_nr)
-			break;
 		nr++;
 	}
 


  reply	other threads:[~2020-11-09 18:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-09 18:17 [PATCH 0/4] xfs: fix various scrub problems Darrick J. Wong
2020-11-09 18:17 ` Darrick J. Wong [this message]
2020-11-10 18:35   ` [PATCH 1/4] xfs: fix brainos in the refcount scrubber's rmap fragment processor Christoph Hellwig
2020-11-12 12:51   ` Chandan Babu R
2020-11-12 16:05     ` Darrick J. Wong
2020-11-13  5:11       ` Chandan Babu R
2020-11-09 18:17 ` [PATCH 2/4] xfs: fix the minrecs logic when dealing with inode root child blocks Darrick J. Wong
2020-11-13  6:35   ` Chandan Babu R
2020-11-14 10:39   ` Christoph Hellwig
2020-11-09 18:17 ` [PATCH 3/4] xfs: strengthen rmap record flags checking Darrick J. Wong
2020-11-13  7:02   ` Chandan Babu R
2020-11-14 10:40   ` Christoph Hellwig
2020-11-09 18:17 ` [PATCH 4/4] xfs: directory scrub should check the null bestfree entries too Darrick J. Wong
2020-11-13  9:08   ` Chandan Babu R
2020-11-14 10:40   ` 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=160494585913.772802.17231950418756379430.stgit@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    /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.