From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 3/3] xfs: validate btree records on retreival
Date: Tue, 5 Jun 2018 15:08:13 +1000 [thread overview]
Message-ID: <20180605050813.GE10363@dastard> (raw)
In-Reply-To: <20180605043916.GB10363@dastard>
On Tue, Jun 05, 2018 at 02:39:16PM +1000, Dave Chinner wrote:
> On Mon, Jun 04, 2018 at 09:02:32PM -0700, Darrick J. Wong wrote:
> > On Tue, Jun 05, 2018 at 12:43:13PM +1000, Dave Chinner wrote:
> > > From: Dave Chinner <dchinner@redhat.com>
> > >
> > > So we don't check the validity of records as we walk the btree. When
> > > there are corrupt records in the free space btree (e.g. zero
> > > startblock/length or beyond EOAG) we just blindly use it and things
> > > go bad from there. That leads to assert failures on debug kernels
> > > like this:
> ....
> > > @@ -222,12 +224,24 @@ xfs_alloc_get_rec(
> > > if (error || !(*stat))
> > > return error;
> > > if (rec->alloc.ar_blockcount == 0)
> > > - return -EFSCORRUPTED;
> > > + goto out_bad_rec;
> > >
> > > *bno = be32_to_cpu(rec->alloc.ar_startblock);
> > > *len = be32_to_cpu(rec->alloc.ar_blockcount);
> > >
> > > - return error;
> > > + if (!xfs_verify_agbno(mp, agno, *bno) ||
> > > + !xfs_verify_agbno(mp, agno, *bno + *len - 1))
> >
> > What about overflows?
>
> I guess that also means I have to add a (*bno > *bno + *len) check
> because it's all unsigned, right?
>
> ....
>
> > > + xfs_inobt_btrec_to_irec(mp, rec, irec);
> > > +
> > > + if (!xfs_verify_agino(mp, agno, irec->ir_startino))
> > > + goto out_bad_rec;
> > > + if (irec->ir_count < XFS_INODES_PER_HOLEMASK_BIT ||
> > > + irec->ir_count > XFS_INODES_PER_CHUNK)
> > > + goto out_bad_rec;
> > > + if (irec->ir_freecount > XFS_INODES_PER_CHUNK)
> > > + goto out_bad_rec;
> > > +
> > > + /* if there are no holes, return the first available offset */
> > > + if (!xfs_inobt_issparse(irec->ir_holemask))
> > > + realfree = irec->ir_free;
> > > + else
> > > + realfree = irec->ir_free & xfs_inobt_irec_to_allocmask(irec);
> > > + if (hweight64(realfree) != irec->ir_freecount)
> > > + goto out_bad_rec;
> >
> > Hmmm... there's a fair amount of shared logic between this and
> > xfs_scrub_iallocbt_rec().
>
> Probably, I did just wrote the checks from first principles.
xfs_scrub_iallocbt_rec() is a lot more heavyweight. It does a lot
more stuff that what I just added, but I'm not sure it will improve
runtime corruption dtection all that much more. i.e I feel like the
additional checking falls on the wrong side of the cost/benefit
line.
Yeah, I know that line is kinda blurry....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2018-06-05 5:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-05 2:43 [PATCH 0/3] xfs: more verifications! Dave Chinner
2018-06-05 2:43 ` [PATCH 1/3] xfs: catch bad stripe alignment configurations Dave Chinner
2018-06-05 3:44 ` Darrick J. Wong
2018-06-05 2:43 ` [PATCH 2/3] xfs: verify extent size hint is valid in inode verifier Dave Chinner
2018-06-05 4:08 ` Darrick J. Wong
2018-06-05 4:24 ` Dave Chinner
2018-06-05 4:28 ` Darrick J. Wong
2018-06-05 4:47 ` Dave Chinner
2018-06-05 2:43 ` [PATCH 3/3] xfs: validate btree records on retreival Dave Chinner
2018-06-05 4:02 ` Darrick J. Wong
2018-06-05 4:39 ` Dave Chinner
2018-06-05 5:08 ` Dave Chinner [this message]
2018-06-05 2:57 ` [PATCH 4/3] xfs: verify root inode more thoroughly Dave Chinner
2018-06-05 4:06 ` Darrick J. Wong
2018-06-05 5:30 ` Dave Chinner
2018-06-05 3:38 ` [PATCH 0/3] xfs: more verifications! Darrick J. Wong
2018-06-05 4:44 ` Dave Chinner
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=20180605050813.GE10363@dastard \
--to=david@fromorbit.com \
--cc=darrick.wong@oracle.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.