| Message ID | 20190115170820.GB12689@magnolia (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | xfs: don't crash when read verifier reports errors with null b_ops | expand |
On Tue, Jan 15, 2019 at 09:08:20AM -0800, Darrick J. Wong wrote: > From: Darrick J. Wong <darrick.wong@oracle.com> > > In xrep_findroot_block, we work out the btree type and correctness of a > given block by calling different btree verifiers on root block > candidates. However, we leave the NULL b_ops while ->verify_read > validates the block, which means that if the verifier calls > xfs_buf_verifier_error it'll crash on the null b_ops. Fix it to avoid > this crash. > > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> > --- > FWIW I also thought about stuffing in a fake b_ops while xrep_findroot > is calling a candidate read verifier, but thought that might just > confuse things more? > --- > fs/xfs/xfs_error.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/xfs/xfs_error.c b/fs/xfs/xfs_error.c > index 9866f542e77b..2a02be280769 100644 > --- a/fs/xfs/xfs_error.c > +++ b/fs/xfs/xfs_error.c > @@ -359,7 +359,7 @@ xfs_buf_verifier_error( > > xfs_alert(mp, "Metadata %s detected at %pS, %s block 0x%llx %s", > bp->b_error == -EFSBADCRC ? "CRC error" : "corruption", > - fa, bp->b_ops->name, bp->b_bn, name); > + fa, bp->b_ops ? bp->b_ops->name : "unknown", bp->b_bn, name); Looks fine, but can you add a comment to xfs_buf_verifier_error() that says that some callers might be running the verifiers themselves rather than through the b_ops structure and so it may be null... Cheers, Dave.
On Wed, Jan 16, 2019 at 07:23:36AM +1100, Dave Chinner wrote: > On Tue, Jan 15, 2019 at 09:08:20AM -0800, Darrick J. Wong wrote: > > From: Darrick J. Wong <darrick.wong@oracle.com> > > > > In xrep_findroot_block, we work out the btree type and correctness of a > > given block by calling different btree verifiers on root block > > candidates. However, we leave the NULL b_ops while ->verify_read > > validates the block, which means that if the verifier calls > > xfs_buf_verifier_error it'll crash on the null b_ops. Fix it to avoid > > this crash. > > > > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> > > --- > > FWIW I also thought about stuffing in a fake b_ops while xrep_findroot > > is calling a candidate read verifier, but thought that might just > > confuse things more? > > --- > > fs/xfs/xfs_error.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/fs/xfs/xfs_error.c b/fs/xfs/xfs_error.c > > index 9866f542e77b..2a02be280769 100644 > > --- a/fs/xfs/xfs_error.c > > +++ b/fs/xfs/xfs_error.c > > @@ -359,7 +359,7 @@ xfs_buf_verifier_error( > > > > xfs_alert(mp, "Metadata %s detected at %pS, %s block 0x%llx %s", > > bp->b_error == -EFSBADCRC ? "CRC error" : "corruption", > > - fa, bp->b_ops->name, bp->b_bn, name); > > + fa, bp->b_ops ? bp->b_ops->name : "unknown", bp->b_bn, name); > > Looks fine, but can you add a comment to xfs_buf_verifier_error() > that says that some callers might be running the verifiers > themselves rather than through the b_ops structure and so it may be > null... Will do. --D > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com
diff --git a/fs/xfs/xfs_error.c b/fs/xfs/xfs_error.c index 9866f542e77b..2a02be280769 100644 --- a/fs/xfs/xfs_error.c +++ b/fs/xfs/xfs_error.c @@ -359,7 +359,7 @@ xfs_buf_verifier_error( xfs_alert(mp, "Metadata %s detected at %pS, %s block 0x%llx %s", bp->b_error == -EFSBADCRC ? "CRC error" : "corruption", - fa, bp->b_ops->name, bp->b_bn, name); + fa, bp->b_ops ? bp->b_ops->name : "unknown", bp->b_bn, name); xfs_alert(mp, "Unmount and run xfs_repair");