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

["Darrick J. Wong" <djwong@kernel.org>]

On Mon, Oct 13, 2025 at 08:29:42AM +0200, Christoph Hellwig wrote:
> 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?

I'll send a patch once I make sure it actually fixes all the new online
fsck test failures in -rc1.

--D