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

[Christoph Hellwig <hch@lst.de>]

On Sun, Oct 12, 2025 at 10:46:47PM -0700, Darrick J. Wong wrote:
> I just pulled 6.18-rc1 and noticed that the rmapbt repair now dumps a
> bunch of warnings about daddr 0 being "beyond" EOFS in the xfbtree that
> holds the in-memory rmap data.
> 
> I think the reason for this is that xfs_daddr_t is actually a s64 value,
> so the comparison in xfs_buf_map_verify
> 
> 	if (map->bm_bn < 0 || map->bm_bn >= btp->bt_nr_sectors) {
> 
> is actually comparing 0 against -1, so the second part of the if test is
> actually true.  I'm not sure what a good fix here would be?  Maybe
> 
> #define XFS_DADDR_MAX	((xfs_daddr_t)S64_MAX)
> 
> and then
> 
> 	/* The maximum size of the buftarg is only known once the sb is read. */
> 	btp->bt_nr_sectors = XFS_DADDR_MAX;
> 
> Hm?

Oh, right the switch to use a xfs_daddr_t means the value is signed
now, and the -1 cast won't get the max value.  Your idea sounds good
to me, do you want to send a patch or should I?