From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Gruenbacher Date: Tue, 13 Jun 2023 15:33:15 +0200 Subject: [Cluster-devel] [PATCH 6/8] gfs2: Rework freeze / thaw logic In-Reply-To: References: <20230612163347.1293077-1-agruenba@redhat.com> <20230612163347.1293077-7-agruenba@redhat.com> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tue, Jun 13, 2023 at 3:05?PM Alexander Aring wrote: > Hi Andreas, > > On Mon, Jun 12, 2023 at 12:33?PM Andreas Gruenbacher > wrote: > ... > > > > @@ -152,24 +151,18 @@ static void signal_our_withdraw(struct gfs2_sbd *sdp) > > */ > > clear_bit(SDF_JOURNAL_LIVE, &sdp->sd_flags); > > if (!sb_rdonly(sdp->sd_vfs)) { > > - struct gfs2_holder freeze_gh; > > - > > - gfs2_holder_mark_uninitialized(&freeze_gh); > > - if (sdp->sd_freeze_gl && > > - !gfs2_glock_is_locked_by_me(sdp->sd_freeze_gl)) { > > - ret = gfs2_freeze_lock_shared(sdp, &freeze_gh, > > - log_write_allowed ? 0 : LM_FLAG_TRY); > > - if (ret == GLR_TRYFAILED) > > - ret = 0; > > - } > > - if (!ret) > > - gfs2_make_fs_ro(sdp); > > + bool locked = mutex_trylock(&sdp->sd_freeze_mutex); > > + > > + gfs2_make_fs_ro(sdp); > > + > > + if (locked) > > + mutex_unlock(&sdp->sd_freeze_mutex); > > I am not sure if I overlooked something here, for me it looks like the > application does not care about if sd_freeze_mutex is locked or not > because the introduced locked boolean will never be evaluated? > > What am I missing here? This is to withdraw the filesystem. We're trying to acquire sd_freeze_mutex to prevent local races, but if we can't get it, we still go ahead and mark the filesystem read-only. Then we unlock sd_freeze_mutex, but only if we've locked it before. This is a bit ugly, but I don't have any better ideas right now. Thanks, Andreas