public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox