[Cluster-devel] [PATCH] gfs2: acquire sd_log_flush_lock in gfs2_trans_remove_revoke

[Cluster-devel] [PATCH] gfs2: acquire sd_log_flush_lock in gfs2_trans_remove_revoke

[Niels Dossche]

gfs2_log_release_revokes states in its function documentation that
sdp->sd_log_flush_lock must be held. The operations on
sd_log_revokes_available are always protected under that lock. All
callers except gfs2_trans_remove_revoke hold the lock.
Acquire that lock in gfs2_trans_remove_revoke. The other callsites use a
read lock as well.

This bug was found using my experimental own-developed static analysis
tool, which reported the missing lock on v6.0-rc5. I manually verified
this bug report by doing code review as well. I compile tested and
runtime checked that the required lock is not held on a x86-64 config.
After applying this patch, my analyser no longer reports this
potential bug.

Fixes: 2129b4288852 ("gfs2: Per-revoke accounting in transactions")
Signed-off-by: Niels Dossche <dossche.niels@gmail.com>
---
 fs/gfs2/trans.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/gfs2/trans.c b/fs/gfs2/trans.c
index 63fec11ef2ce..468e4da20a44 100644
--- a/fs/gfs2/trans.c
+++ b/fs/gfs2/trans.c
@@ -301,6 +301,7 @@ void gfs2_trans_remove_revoke(struct gfs2_sbd *sdp, u64 blkno, unsigned int len)
 	struct gfs2_bufdata *bd, *tmp;
 	unsigned int n = len;
 
+	down_read(&sdp->sd_log_flush_lock);
 	gfs2_log_lock(sdp);
 	list_for_each_entry_safe(bd, tmp, &sdp->sd_log_revokes, bd_list) {
 		if ((bd->bd_blkno >= blkno) && (bd->bd_blkno < (blkno + len))) {
@@ -316,6 +317,7 @@ void gfs2_trans_remove_revoke(struct gfs2_sbd *sdp, u64 blkno, unsigned int len)
 		}
 	}
 	gfs2_log_unlock(sdp);
+	up_read(&sdp->sd_log_flush_lock);
 }
 
 void gfs2_trans_free(struct gfs2_sbd *sdp, struct gfs2_trans *tr)
-- 
2.37.3