All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 02/12] xfs: check deferred refcount op continuation parameters
Date: Fri, 28 Oct 2022 07:49:57 +1100	[thread overview]
Message-ID: <20221027204957.GR3600936@dread.disaster.area> (raw)
In-Reply-To: <166689085464.3788582.2756559047908250104.stgit@magnolia>

On Thu, Oct 27, 2022 at 10:14:14AM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> If we're in the middle of a deferred refcount operation and decide to
> roll the transaction to avoid overflowing the transaction space, we need
> to check the new agbno/aglen parameters that we're about to record in
> the new intent.  Specifically, we need to check that the new extent is
> completely within the filesystem, and that continuation does not put us
> into a different AG.
> 
> If the keys of a node block are wrong, the lookup to resume an
> xfs_refcount_adjust_extents operation can put us into the wrong record
> block.  If this happens, we might not find that we run out of aglen at
> an exact record boundary, which will cause the loop control to do the
> wrong thing.
> 
> The previous patch should take care of that problem, but let's add this
> extra sanity check to stop corruption problems sooner than later.
> 
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> ---
>  fs/xfs/libxfs/xfs_refcount.c |   48 ++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 46 insertions(+), 2 deletions(-)
> 
> 
> diff --git a/fs/xfs/libxfs/xfs_refcount.c b/fs/xfs/libxfs/xfs_refcount.c
> index 831353ba96dc..c6aa832a8713 100644
> --- a/fs/xfs/libxfs/xfs_refcount.c
> +++ b/fs/xfs/libxfs/xfs_refcount.c
> @@ -1138,6 +1138,44 @@ xfs_refcount_finish_one_cleanup(
>  		xfs_trans_brelse(tp, agbp);
>  }
>  
> +/*
> + * Set up a continuation a deferred refcount operation by updating the intent.
> + * Checks to make sure we're not going to run off the end of the AG.
> + */
> +static inline int
> +xfs_refcount_continue_op(
> +	struct xfs_btree_cur		*cur,
> +	xfs_fsblock_t			startblock,
> +	xfs_agblock_t			new_agbno,
> +	xfs_extlen_t			new_len,
> +	xfs_fsblock_t			*fsbp)
> +{
> +	struct xfs_mount		*mp = cur->bc_mp;
> +	struct xfs_perag		*pag = cur->bc_ag.pag;
> +	xfs_fsblock_t			new_fsbno;
> +	xfs_agnumber_t			old_agno;
> +
> +	old_agno = XFS_FSB_TO_AGNO(mp, startblock);
> +	new_fsbno = XFS_AGB_TO_FSB(mp, pag->pag_agno, new_agbno);
> +
> +	/*
> +	 * If we don't have any work left to do, then there's no need
> +	 * to perform the validation of the new parameters.
> +	 */
> +	if (!new_len)
> +		goto done;

Shouldn't we be validating new_fsbno rather than just returning
whatever we calculated here?

> +	if (XFS_IS_CORRUPT(mp, !xfs_verify_fsbext(mp, new_fsbno, new_len)))
> +		return -EFSCORRUPTED;
> +
> +	if (XFS_IS_CORRUPT(mp, old_agno != XFS_FSB_TO_AGNO(mp, new_fsbno)))
> +		return -EFSCORRUPTED;

We already know what agno new_fsbno sits in - we calculated it
directly from pag->pag_agno above, so this can jsut check against
pag->pag_agno directly, right?

i.e.

	if (XFS_IS_CORRUPT(mp,
			XFS_FSB_TO_AGNO(mp, startblock) != pag->pag_agno))
		return -EFSCORRUPTED;

and we don't need the local variable for it....

Cheers,

Dave.

-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2022-10-27 20:58 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-27 17:14 [PATCHSET v2 00/12] xfs: improve runtime refcountbt corruption detection Darrick J. Wong
2022-10-27 17:14 ` [PATCH 01/12] xfs: make sure aglen never goes negative in xfs_refcount_adjust_extents Darrick J. Wong
2022-10-27 20:41   ` Dave Chinner
2022-10-27 17:14 ` [PATCH 02/12] xfs: check deferred refcount op continuation parameters Darrick J. Wong
2022-10-27 20:49   ` Dave Chinner [this message]
2022-10-27 21:32     ` Darrick J. Wong
2022-10-27 21:42       ` Darrick J. Wong
2022-10-27 22:24       ` Dave Chinner
2022-10-27 23:25         ` Darrick J. Wong
2022-10-27 21:54   ` [PATCH v2.1 " Darrick J. Wong
2022-10-27 17:14 ` [PATCH 03/12] xfs: move _irec structs to xfs_types.h Darrick J. Wong
2022-10-27 17:14 ` [PATCH 04/12] xfs: refactor refcount record usage in xchk_refcountbt_rec Darrick J. Wong
2022-10-27 17:14 ` [PATCH 05/12] xfs: track cow/shared record domains explicitly in xfs_refcount_irec Darrick J. Wong
2022-10-27 21:03   ` Dave Chinner
2022-10-27 21:10     ` Darrick J. Wong
2022-10-27 17:14 ` [PATCH 06/12] xfs: report refcount domain in tracepoints Darrick J. Wong
2022-10-27 21:05   ` Dave Chinner
2022-10-27 17:14 ` [PATCH 07/12] xfs: refactor domain and refcount checking Darrick J. Wong
2022-10-27 21:07   ` Dave Chinner
2022-10-27 17:14 ` [PATCH 08/12] xfs: remove XFS_FIND_RCEXT_SHARED and _COW Darrick J. Wong
2022-10-27 21:11   ` Dave Chinner
2022-10-27 17:14 ` [PATCH 09/12] xfs: check record domain when accessing refcount records Darrick J. Wong
2022-10-27 21:15   ` Dave Chinner
2022-10-27 21:33     ` Darrick J. Wong
2022-10-27 17:14 ` [PATCH 10/12] xfs: fix agblocks check in the cow leftover recovery function Darrick J. Wong
2022-10-27 21:22   ` Dave Chinner
2022-10-27 17:15 ` [PATCH 11/12] xfs: fix uninitialized list head in struct xfs_refcount_recovery Darrick J. Wong
2022-10-27 21:24   ` Dave Chinner
2022-10-27 17:15 ` [PATCH 12/12] xfs: rename XFS_REFC_COW_START to _COWFLAG Darrick J. Wong
2022-10-27 21:25   ` 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=20221027204957.GR3600936@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.