From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-xfs@vger.kernel.org, david@fromorbit.com,
allison.henderson@oracle.com
Subject: Re: [PATCH 1/4] xfs: xrep_findroot_block should reject root blocks with siblings
Date: Thu, 9 Aug 2018 10:43:17 -0700 [thread overview]
Message-ID: <20180809174317.GL30972@magnolia> (raw)
In-Reply-To: <20180809130839.GB21639@bfoster>
On Thu, Aug 09, 2018 at 09:08:39AM -0400, Brian Foster wrote:
> On Tue, Aug 07, 2018 at 08:57:06PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> >
> > In xrep_findroot_block, if we find a candidate root block with sibling
> > pointers or sibling blocks on the same tree level, we should not return
> > that block as a tree root because root blocks cannot have siblings.
> >
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > ---
> > fs/xfs/scrub/repair.c | 17 +++++++++++++++++
> > 1 file changed, 17 insertions(+)
> >
> >
> > diff --git a/fs/xfs/scrub/repair.c b/fs/xfs/scrub/repair.c
> > index 85b048b341a0..6c199e2ebb81 100644
> > --- a/fs/xfs/scrub/repair.c
> > +++ b/fs/xfs/scrub/repair.c
> > @@ -727,6 +727,23 @@ xrep_findroot_block(
> > bp->b_ops->verify_read(bp);
> > if (bp->b_error)
> > goto out;
> > +
> > + /* Root blocks can't have siblings. */
> > + if (btblock->bb_u.s.bb_leftsib != cpu_to_be32(NULLAGBLOCK) ||
> > + btblock->bb_u.s.bb_rightsib != cpu_to_be32(NULLAGBLOCK))
> > + goto out;
> > +
> > + /*
> > + * If we find a second block at this level, ignore this level because
> > + * it can't possibly be a root level. Maybe we'll find a higher level,
> > + * or maybe the rmap information is garbage.
> > + */
> > + if (fab->root != NULLAGBLOCK &&
> > + fab->height == xfs_btree_get_level(btblock) + 1) {
> > + fab->root = NULLAGBLOCK;
> > + goto out;
> > + }
>
> Ok, but is this enough? Won't resetting fab->root like this mean that
> we'd just reassign it to the next block we find at this level? I'm
> wondering if we should maintain ->height independently and anticipate
> that (height == <valid> && root == NULLAGBLOCK) means we couldn't find a
> valid root. That may also allow for more efficient height filtering
> during the query.
Working through this again, I think we could just set fab->root = 0
when we encounter this situation. I think the two height checks could
be combined as well, so I'll retest and repost.
Roughly, I think this whole section could be restructured as:
/* Make sure we pass the verifiers. */
...
/* Root blocks can't have siblings. */
...
/* If we've recorded a root candidate... */
block_level = xfs_btree_get_level(btblock);
if (fab->root != NULLAGBLOCK) {
/*
* ...and this no-sibling root block candidate has the same
* level as the recorded candidate, there's no way we're going
* to accept any candidates at this tree level. Stash a root
* block of zero because the height is still valid, but no AG
* btree can root at agblock 0. Callers should verify the root
* agbno.
*/
if (block_level + 1 == fab->height) {
fab->root = 0;
goto out;
}
/*
* ...and this no-sibling root block is lower in the tree than
* the recorded root block candidate, just ignore it. There's
* still a strong chance that something is wrong with the btree
* itself, but that's not what we're fixing right now.
*/
if (block_level < fab->height)
goto out;
}
/* Record the candidate root block */
...
--D
>
> Brian
>
> > +
> > fab->root = agbno;
> > fab->height = xfs_btree_get_level(btblock) + 1;
> > *found_it = true;
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-08-09 20:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-08 3:56 [PATCH v17.2 0/4] xfs-4.19: online repair support Darrick J. Wong
2018-08-08 3:57 ` [PATCH 1/4] xfs: xrep_findroot_block should reject root blocks with siblings Darrick J. Wong
2018-08-09 13:08 ` Brian Foster
2018-08-09 17:43 ` Darrick J. Wong [this message]
2018-08-08 3:57 ` [PATCH 2/4] xfs: repair the AGF Darrick J. Wong
2018-08-09 13:08 ` Brian Foster
2018-08-08 3:57 ` [PATCH 3/4] xfs: repair the AGFL Darrick J. Wong
2018-08-09 13:08 ` Brian Foster
2018-08-09 18:06 ` Darrick J. Wong
2018-08-10 10:34 ` Brian Foster
2018-08-10 14:58 ` Darrick J. Wong
2018-08-08 3:57 ` [PATCH 4/4] xfs: repair the AGI Darrick J. Wong
2018-08-09 13:09 ` Brian Foster
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=20180809174317.GL30972@magnolia \
--to=darrick.wong@oracle.com \
--cc=allison.henderson@oracle.com \
--cc=bfoster@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).