On Mon, Jul 15, 2024 at 10:32:04AM -0700, Darrick J. Wong wrote: > Did you actually hit this, or did you find it through code inspection? I hit this, but only with the per-rtg rt bitmap, with which this caused an out of bounds access in the new, non-upstream array of RT AVL trees. > AFAICT for attr forks, the (whichfork != XFS_DATA_FORK) check should > have been saving us this whole time? And the (type != XR_INO_RTDATA) > check did the job for the data fork? > > IOWs, is this merely cleaning out a logic bomb, or is it resolving some > false positive/customer complaint? As far as I can tell this is a real bug upstream. If you have a bmap btree block number that when interpreted as a RT extent is also otherwise used you'll get repair finding an incorrect duplicate block. It just seems hard enough to trigger so that no one found it despite being there since day 1 of public xfsprogs releases.
