[PATCH] xfs_repair: take the ag_lock before recording rmap for a bmbt record

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



When the (threaded) inode scanner iterates the blocks of a bmbt tree and
wants to record the bmbt blocks in the in-core rmap database, we have to
take the ag_lock for the AG that the bmbt block is in, or else we can
accidentally corrupt the rmap slab by calling slab_add from two threads.

Reported-by: matorola@xxxxxxxxx
Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
---
 repair/scan.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/repair/scan.c b/repair/scan.c
index 6c9f5e7..ccf60a6 100644
--- a/repair/scan.c
+++ b/repair/scan.c
@@ -386,7 +386,10 @@ _("bad state %d, inode %" PRIu64 " bmap block 0x%" PRIx64 "\n"),
 
 	/* Record BMBT blocks in the reverse-mapping data. */
 	if (check_dups && collect_rmaps) {
+		agno = XFS_FSB_TO_AGNO(mp, bno);
+		pthread_mutex_lock(&ag_locks[agno].lock);
 		error = rmap_add_bmbt_rec(mp, ino, whichfork, bno);
+		pthread_mutex_unlock(&ag_locks[agno].lock);
 		if (error)
 			do_error(
 _("couldn't add inode %"PRIu64" bmbt block %"PRIu64" reverse-mapping data."),
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux