]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
xfs: fix brainos in the refcount scrubber's rmap fragment processor
authorDarrick J. Wong <darrick.wong@oracle.com>
Mon, 9 Nov 2020 00:32:42 +0000 (16:32 -0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 18 Nov 2020 18:18:47 +0000 (19:18 +0100)
commit964e25377fab8e9071c07d8cdf1c9a4fb079285e
tree00a5a9443052cc7a8a378c2f9d7bd816398dbf36
parentb7fec5a9a726e9e2a095d53b6de4e62bf179b481
xfs: fix brainos in the refcount scrubber's rmap fragment processor

[ Upstream commit 54e9b09e153842ab5adb8a460b891e11b39e9c3d ]

Fix some serious WTF in the reference count scrubber's rmap fragment
processing.  The code comment says that this loop is supposed to move
all fragment records starting at or before bno onto the worklist, but
there's no obvious reason why nr (the number of items added) should
increment starting from 1, and breaking the loop when we've added the
target number seems dubious since we could have more rmap fragments that
should have been added to the worklist.

This seems to manifest in xfs/411 when adding one to the refcount field.

Fixes: dbde19da9637 ("xfs: cross-reference the rmapbt data with the refcountbt")
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
fs/xfs/scrub/refcount.c