All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] xfs_repair: take the ag_lock before recording rmap for a bmbt record
@ 2017-08-31 20:12 Darrick J. Wong
  2017-09-01 11:40 ` Carlos Maiolino
  0 siblings, 1 reply; 2+ messages in thread
From: Darrick J. Wong @ 2017-08-31 20:12 UTC (permalink / raw)
  To: Eric Sandeen; +Cc: matorola, xfs

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@gmail.com
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
---
 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."),

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] xfs_repair: take the ag_lock before recording rmap for a bmbt record
  2017-08-31 20:12 [PATCH] xfs_repair: take the ag_lock before recording rmap for a bmbt record Darrick J. Wong
@ 2017-09-01 11:40 ` Carlos Maiolino
  0 siblings, 0 replies; 2+ messages in thread
From: Carlos Maiolino @ 2017-09-01 11:40 UTC (permalink / raw)
  To: Darrick J. Wong; +Cc: Eric Sandeen, matorola, xfs

On Thu, Aug 31, 2017 at 01:12:55PM -0700, Darrick J. Wong wrote:
> 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@gmail.com
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>

Looks good,
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>

> ---
>  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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Carlos

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-09-01 11:40 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-31 20:12 [PATCH] xfs_repair: take the ag_lock before recording rmap for a bmbt record Darrick J. Wong
2017-09-01 11:40 ` Carlos Maiolino

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.