On Tue, Jun 13, 2023 at 3:05 PM Alexander Aring <aahri...@redhat.com> wrote:
> Hi Andreas,
>
> On Mon, Jun 12, 2023 at 12:33 PM Andreas Gruenbacher
> <agrue...@redhat.com> 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
