On Thu, Jan 04, 2018 at 05:24:10PM -0800, Darrick J. Wong wrote:
> On Fri, Jan 05, 2018 at 12:17:14PM +1100, Dave Chinner wrote:
> > On Fri, Dec 22, 2017 at 04:43:02PM -0800, Darrick J. Wong wrote:
> > > From: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
> > >
> > > The superblock validation routines return a variety of error codes to
> > > reject a mount request. For scrub we can assume that the mount
> > > succeeded, so if we see these things appear when scrubbing secondary sb
> > > X, we can treat them all like corruption.
> > >
> > > Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
> > > ---
> > > fs/xfs/scrub/agheader.c | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > >
> > >
> > > diff --git a/fs/xfs/scrub/agheader.c b/fs/xfs/scrub/agheader.c
> > > index b599358..97beb47 100644
> > > --- a/fs/xfs/scrub/agheader.c
> > > +++ b/fs/xfs/scrub/agheader.c
> > > @@ -126,6 +126,22 @@ xfs_scrub_superblock(
> > > error = xfs_trans_read_buf(mp, sc->tp, mp->m_ddev_targp,
> > > XFS_AGB_TO_DADDR(mp, agno, XFS_SB_BLOCK(mp)),
> > > XFS_FSS_TO_BB(mp, 1), 0, &bp, &xfs_sb_buf_ops);
> > > + /*
> > > + * The superblock verifier can return several different error codes
> > > + * if it thinks the superblock doesn't look right. For a mount these
> > > + * would all get bounced back to userspace, but if we're here then the
> > > + * fs mounted successfully, which means that this secondary superblock
> > > + * is simply incorrect. Treat all these codes the same way we treat
> > > + * any corruption.
> > > + */
> > > + switch (error) {
> > > + case -EINVAL: /* also -EWRONGFS */
> > > + case -ENOSYS:
> > > + case -EFBIG:
> > > + error = -EFSCORRUPTED;
> > > + default:
> > > + break;
> > > + }
> > > if (!xfs_scrub_process_error(sc, agno, XFS_SB_BLOCK(mp), &error))
> > > return error;
> >
> > Yes, this change looks fine, so
> >
> > Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>
> >
> > However, what I just realised is that the in-memory primary
> > superblock buffer that we do all our normal modification/logging
> > work on is an uncached buffer that accessed through xfs_getsb(), not
> > a cached buffer we access through xfs_trans_read_buf().
> >
> > Does the scrub code take this into account?
>
> We don't scrub the primary superblock at all, assuming that mount
> will reject bad superblocks for us, and we don't touch the primary
> superblock buffer at all, afaik.
No worries, I couldn't remember what it did here and didn't find an
obvious answer as I looked.
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
