From: Brian Foster <bfoster@redhat.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: david@fromorbit.com, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 3/3] xfs: fix buffer state management in xrep_findroot_block
Date: Fri, 5 Oct 2018 07:59:51 -0400 [thread overview]
Message-ID: <20181005115950.GC54400@bfoster> (raw)
In-Reply-To: <153870047729.29695.18042015772366432041.stgit@magnolia>
On Thu, Oct 04, 2018 at 05:47:57PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
>
> We don't handle buffer state properly in online repair's findroot
> routine. If a buffer already has b_ops set, we don't ever want to touch
> that, and we don't want to call the read verifiers on a buffer that
> could be dirty (CRCs are only recomputed during log checkpoints).
>
> Therefore, be more careful about what we do with a buffer -- if someone
> else already attached ops that are not the ones for this btree type,
> just ignore the buffer. We only attach our btree type's buf ops if it
> matches the magic/uuid and structure checks.
>
> We also modify xfs_buf_read_map to allow callers to set buffer ops on a
> DONE buffer with NULL ops so that repair doesn't leave behind buffers
> which won't have buffers attached to them.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
> fs/xfs/scrub/repair.c | 63 +++++++++++++++++++++++++++++++++++++-----------
> fs/xfs/xfs_trans.h | 1 +
> fs/xfs/xfs_trans_buf.c | 13 ++++++++++
> 3 files changed, 63 insertions(+), 14 deletions(-)
>
>
> diff --git a/fs/xfs/scrub/repair.c b/fs/xfs/scrub/repair.c
> index 63786341ac2a..cebaebb26566 100644
> --- a/fs/xfs/scrub/repair.c
> +++ b/fs/xfs/scrub/repair.c
...
> @@ -718,28 +720,61 @@ xrep_findroot_block(
> return error;
> }
>
...
> + /*
> + * If the buffer already has ops applied and they're not the ones for
> + * this btree type, we know this block doesn't match the btree and we
> + * can bail out.
> + *
> + * If the buffer ops match ours, someone else has already validated
> + * the block for us, so we can move on to checking if this is a root
> + * block candidate.
> + *
> + * If the buffer does not have ops, nobody has successfully validated
> + * the contents and the buffer cannot be dirty. If the magic, uuid,
> + * and structure match this btree type then we'll move on to checking
> + * if it's a root block candidate. If there is no match, bail out.
> + */
> + if (bp->b_ops) {
> + if (bp->b_ops != fab->buf_ops)
> + goto out;
> + } else {
> + ASSERT(!xfs_trans_buf_is_dirty(bp));
> + if (!uuid_equal(&btblock->bb_u.s.bb_uuid,
> + &mp->m_sb.sb_meta_uuid))
> + goto out;
> + fab->buf_ops->verify_read(bp);
> + if (bp->b_error)
> + goto out;
I guess this is related to my question on the previous patch. If the
verifier fails, we leave the XBF_DONE buffer around with ->b_ops == NULL
and ->b_error != 0.
I suppose somebody should eventually attach a verifier before this
buffer is ever really used, but I think I'd feel a little better about
this if we immediately cleaned up the side effects of using the wrong
verifier rather than potentially leaking an error to other contexts
where it has no relevance. That aside, this all looks fine to me.
Brian
> + bp->b_ops = fab->buf_ops;
> + }
>
> /*
> * This block passes the magic/uuid and verifier tests for this btree
> diff --git a/fs/xfs/xfs_trans.h b/fs/xfs/xfs_trans.h
> index c3d278e96ad1..a0c5dbda18aa 100644
> --- a/fs/xfs/xfs_trans.h
> +++ b/fs/xfs/xfs_trans.h
> @@ -220,6 +220,7 @@ void xfs_trans_ijoin(struct xfs_trans *, struct xfs_inode *, uint);
> void xfs_trans_log_buf(struct xfs_trans *, struct xfs_buf *, uint,
> uint);
> void xfs_trans_dirty_buf(struct xfs_trans *, struct xfs_buf *);
> +bool xfs_trans_buf_is_dirty(struct xfs_buf *bp);
> void xfs_trans_log_inode(xfs_trans_t *, struct xfs_inode *, uint);
>
> void xfs_extent_free_init_defer_op(void);
> diff --git a/fs/xfs/xfs_trans_buf.c b/fs/xfs/xfs_trans_buf.c
> index b0ba2ca9cca3..93a053c700dd 100644
> --- a/fs/xfs/xfs_trans_buf.c
> +++ b/fs/xfs/xfs_trans_buf.c
> @@ -349,6 +349,19 @@ xfs_trans_read_buf_map(
>
> }
>
> +/* Has this buffer been dirtied by anyone? */
> +bool
> +xfs_trans_buf_is_dirty(
> + struct xfs_buf *bp)
> +{
> + struct xfs_buf_log_item *bip = bp->b_log_item;
> +
> + if (!bip)
> + return false;
> + ASSERT(bip->bli_item.li_type == XFS_LI_BUF);
> + return test_bit(XFS_LI_DIRTY, &bip->bli_item.li_flags);
> +}
> +
> /*
> * Release the buffer bp which was previously acquired with one of the
> * xfs_trans_... buffer allocation routines if the buffer has not
>
next prev parent reply other threads:[~2018-10-05 18:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-05 0:47 [PATCH v3 0/3] xfs-4.20: scrub fixes Darrick J. Wong
2018-10-05 0:47 ` [PATCH 1/3] xfs: xrep_findroot_block should reject root blocks with siblings Darrick J. Wong
2018-10-05 0:47 ` [PATCH 2/3] xfs: always assign buffer verifiers when one is provided Darrick J. Wong
2018-10-05 11:57 ` Brian Foster
2018-10-05 17:02 ` Darrick J. Wong
2018-10-06 3:15 ` Darrick J. Wong
2018-10-06 10:25 ` Christoph Hellwig
2018-10-05 0:47 ` [PATCH 3/3] xfs: fix buffer state management in xrep_findroot_block Darrick J. Wong
2018-10-05 11:59 ` Brian Foster [this message]
2018-10-05 15:11 ` Darrick J. Wong
-- strict thread matches above, loose matches on Subject: below --
2018-10-09 4:19 [PATCH v4 0/3] xfs-4.20: scrub fixes Darrick J. Wong
2018-10-09 4:19 ` [PATCH 3/3] xfs: fix buffer state management in xrep_findroot_block Darrick J. Wong
2018-10-09 12:16 ` Brian Foster
2018-10-09 16:19 ` Darrick J. Wong
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=20181005115950.GC54400@bfoster \
--to=bfoster@redhat.com \
--cc=darrick.wong@oracle.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).