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.ni...@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
