Re: [PATCH 1/2] xfs: track the number of blocks in each buftarg

[Dave Chinner <david@fromorbit.com>]

On Tue, Sep 16, 2025 at 06:52:31AM -0700, Christoph Hellwig wrote:
> Add a bt_nr_blocks to track the number of blocks in each buftarg, and
> replace the check that hard codes sb_dblock in xfs_buf_map_verify with
> this new value so that it is correct for non-ddev buftargs.  The
> RT buftarg only has a superblock in the first block, so it is unlikely
> to trigger this, or are we likely to ever have enough blocks in the
> in-memory buftargs, but we might as well get the check right.
> 
> Fixes: 10616b806d1d ("xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end")
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  fs/xfs/xfs_buf.c              | 38 +++++++++++++++++++----------------
>  fs/xfs/xfs_buf.h              |  4 +++-
>  fs/xfs/xfs_buf_item_recover.c |  7 +++++++
>  fs/xfs/xfs_super.c            |  7 ++++---
>  fs/xfs/xfs_trans.c            | 21 +++++++++----------
>  5 files changed, 45 insertions(+), 32 deletions(-)
> 
> diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
> index f9ef3b2a332a..b9b89f1243a0 100644
> --- a/fs/xfs/xfs_buf.c
> +++ b/fs/xfs/xfs_buf.c
> @@ -397,7 +397,7 @@ xfs_buf_map_verify(
>  	 * Corrupted block numbers can get through to here, unfortunately, so we
>  	 * have to check that the buffer falls within the filesystem bounds.
>  	 */
> -	eofs = XFS_FSB_TO_BB(btp->bt_mount, btp->bt_mount->m_sb.sb_dblocks);
> +	eofs = XFS_FSB_TO_BB(btp->bt_mount, btp->bt_nr_blocks);

Why store the number of blocks in filesystem block units? The
buffer cache/buftarg uses daddr addressing, and this is the only
place in the whole buffer cache where we've needed to do filesystem
block to daddr unit conversion.

IMO it should be stored in daddr units to be consistent with all
other buffer cache addresses and length, with the conversion to
daddr units being done by the xfs_configure_buftarg() caller. This
gets rid of this unit conversion in the lookup fast path in addition
to removing to pointer chase through the mount to the superblock.

This means the only remaining fast path references to the xfs_mount
in the lookup path is the stats update code.  If the stats then got
moved to the buftarg, then we don't access the xfs_mount at all in
the buffer cache lookup path except when an error occurs...

Other than that, the code looks fine.

-Dave.
-- 
Dave Chinner
david@fromorbit.com