summaryrefslogtreecommitdiffstats
path: root/mm/cma_debug.c
diff options
context:
space:
mode:
authorDarrick J. Wong <darrick.wong@oracle.com>2020-11-08 16:32:42 -0800
committerDarrick J. Wong <darrick.wong@oracle.com>2020-11-10 16:48:03 -0800
commit54e9b09e153842ab5adb8a460b891e11b39e9c3d (patch)
treeca82b2c3306f5277d703ee3d98ba77999b22e6dd /mm/cma_debug.c
parent6ff646b2ceb0eec916101877f38da0b73e3a5b7f (diff)
downloadlinux-54e9b09e153842ab5adb8a460b891e11b39e9c3d.tar.gz
linux-54e9b09e153842ab5adb8a460b891e11b39e9c3d.tar.bz2
linux-54e9b09e153842ab5adb8a460b891e11b39e9c3d.zip
xfs: fix brainos in the refcount scrubber's rmap fragment processor
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>
Diffstat (limited to 'mm/cma_debug.c')
0 files changed, 0 insertions, 0 deletions