From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH RFC] xfs: support magic value in xfs_buf_ops
Date: Thu, 24 Jan 2019 11:08:46 -0800 [thread overview]
Message-ID: <20190124190846.GC4368@magnolia> (raw)
In-Reply-To: <20190124155440.46469-1-bfoster@redhat.com>
On Thu, Jan 24, 2019 at 10:54:40AM -0500, Brian Foster wrote:
> Add a field to specify the v4 and v5 magic values in xfs_buf_ops.
> This allows otherwise identical verifiers to distinguish between
> and verify different magic values (inobt vs. finobt buffers). This
> also facilitates verification of the appropriate magic value based
> on superblock version.
>
> The magic field is optional and is free to be used as appropriate
> for each particular verifier.
>
> Signed-off-by: Brian Foster <bfoster@redhat.com>
> ---
>
> Hi all,
>
> What do folks think of something like this as a lightweight (and
> untested) means to do proper [f]inobt magic verification? For reference,
> the initial version of this put together to help root cause a user
> report is here[1]. I was hoping to do the same thing with less code
> duplication. A couple things that come to mind:
>
> 1. I know scrub has at least one place where we invoke the verifier with
> ->b_ops == NULL, which will cause this to explode. Could we fix that up
> to assign and reset ->b_ops to accommodate something like this, or is
> that problematic?
IIRC one of the scrub findroot reviewers didn't like the idea of scrub
setting b_ops until it was absolutely sure it wanted to. I think it's
actually ok to patch it in temporarily while running the read verifier
since we have the buffer locked and patch it out afterwards.
> 2. We have some other verifiers around that actually use the buffer
> magic to set a more specific verifier. See xfs_da3_node_read_verify()
> for an example. I'm not sure this is all that useful for such higher
> level verifiers, but I think we'd at least be able to use it for the
> underlying verifiers. That might provide some extra sb version vs. magic
> sanity checking for places that might not already look at the sb version
> (otherwise it's just refactoring).
>
> Thoughts or other ideas before I try to apply this more broadly? Thanks.
Hmm... not sure if I like the idea that you have to find the b_ops
declaration to figure out which magic number the verifier function is
checking, but I don't really have a cogent objection.
--D
> Brian
>
> [1] https://marc.info/?l=linux-xfs&m=154809431726435&w=2
>
> fs/xfs/libxfs/xfs_ialloc_btree.c | 27 +++++++++++++++++----------
> fs/xfs/xfs_buf.h | 1 +
> 2 files changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/fs/xfs/libxfs/xfs_ialloc_btree.c b/fs/xfs/libxfs/xfs_ialloc_btree.c
> index 9b25e7a0df47..59b0cf1d759a 100644
> --- a/fs/xfs/libxfs/xfs_ialloc_btree.c
> +++ b/fs/xfs/libxfs/xfs_ialloc_btree.c
> @@ -259,6 +259,12 @@ xfs_inobt_verify(
> struct xfs_btree_block *block = XFS_BUF_TO_BLOCK(bp);
> xfs_failaddr_t fa;
> unsigned int level;
> + uint32_t magic;
> +
> + ASSERT(bp->b_ops);
> + magic = bp->b_ops->magic[xfs_sb_version_hascrc(&mp->m_sb)];
> + if (block->bb_magic != cpu_to_be32(magic))
> + return __this_address;
>
> /*
> * During growfs operations, we can't verify the exact owner as the
> @@ -270,18 +276,10 @@ xfs_inobt_verify(
> * but beware of the landmine (i.e. need to check pag->pagi_init) if we
> * ever do.
> */
> - switch (block->bb_magic) {
> - case cpu_to_be32(XFS_IBT_CRC_MAGIC):
> - case cpu_to_be32(XFS_FIBT_CRC_MAGIC):
> + if (xfs_sb_version_hascrc(&mp->m_sb)) {
> fa = xfs_btree_sblock_v5hdr_verify(bp);
> if (fa)
> return fa;
> - /* fall through */
> - case cpu_to_be32(XFS_IBT_MAGIC):
> - case cpu_to_be32(XFS_FIBT_MAGIC):
> - break;
> - default:
> - return __this_address;
> }
>
> /* level verification */
> @@ -328,6 +326,15 @@ xfs_inobt_write_verify(
>
> const struct xfs_buf_ops xfs_inobt_buf_ops = {
> .name = "xfs_inobt",
> + .magic = { XFS_IBT_MAGIC, XFS_IBT_CRC_MAGIC },
> + .verify_read = xfs_inobt_read_verify,
> + .verify_write = xfs_inobt_write_verify,
> + .verify_struct = xfs_inobt_verify,
> +};
> +
> +const struct xfs_buf_ops xfs_finobt_buf_ops = {
> + .name = "xfs_finobt",
> + .magic = { XFS_FIBT_MAGIC, XFS_FIBT_CRC_MAGIC },
> .verify_read = xfs_inobt_read_verify,
> .verify_write = xfs_inobt_write_verify,
> .verify_struct = xfs_inobt_verify,
> @@ -389,7 +396,7 @@ static const struct xfs_btree_ops xfs_finobt_ops = {
> .init_rec_from_cur = xfs_inobt_init_rec_from_cur,
> .init_ptr_from_cur = xfs_finobt_init_ptr_from_cur,
> .key_diff = xfs_inobt_key_diff,
> - .buf_ops = &xfs_inobt_buf_ops,
> + .buf_ops = &xfs_finobt_buf_ops,
> .diff_two_keys = xfs_inobt_diff_two_keys,
> .keys_inorder = xfs_inobt_keys_inorder,
> .recs_inorder = xfs_inobt_recs_inorder,
> diff --git a/fs/xfs/xfs_buf.h b/fs/xfs/xfs_buf.h
> index b9f5511ea998..ce61e6b94725 100644
> --- a/fs/xfs/xfs_buf.h
> +++ b/fs/xfs/xfs_buf.h
> @@ -125,6 +125,7 @@ struct xfs_buf_map {
>
> struct xfs_buf_ops {
> char *name;
> + uint32_t magic[2];
> void (*verify_read)(struct xfs_buf *);
> void (*verify_write)(struct xfs_buf *);
> xfs_failaddr_t (*verify_struct)(struct xfs_buf *bp);
> --
> 2.17.2
>
next prev parent reply other threads:[~2019-01-24 19:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-24 15:54 [PATCH RFC] xfs: support magic value in xfs_buf_ops Brian Foster
2019-01-24 19:08 ` Darrick J. Wong [this message]
2019-01-24 22:19 ` Dave Chinner
2019-01-25 14:43 ` Brian Foster
2019-01-27 17:49 ` Darrick J. Wong
2019-01-28 21:06 ` 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=20190124190846.GC4368@magnolia \
--to=darrick.wong@oracle.com \
--cc=bfoster@redhat.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