From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
mcgrof@kernel.org, jack@suse.cz, ruansy.fnst@fujitsu.com
Subject: Re: [PATCH 2/3] fs: wait for partially frozen filesystems
Date: Mon, 12 Jun 2023 11:47:49 -0700 [thread overview]
Message-ID: <20230612184749.GJ11441@frogsfrogsfrogs> (raw)
In-Reply-To: <20230612183302.GH11441@frogsfrogsfrogs>
On Mon, Jun 12, 2023 at 11:33:02AM -0700, Darrick J. Wong wrote:
> On Sun, Jun 11, 2023 at 09:01:48PM -0700, Christoph Hellwig wrote:
> > On Sun, Jun 11, 2023 at 08:15:28PM -0700, Darrick J. Wong wrote:
> > > From: Darrick J. Wong <djwong@kernel.org>
> > >
> > > Jan Kara suggested that when one thread is in the middle of freezing a
> > > filesystem, another thread trying to freeze the same fs but with a
> > > different freeze_holder should wait until the freezer reaches either end
> > > state (UNFROZEN or COMPLETE) instead of returning EBUSY immediately.
> > >
> > > Plumb in the extra coded needed to wait for the fs freezer to reach an
> > > end state and try the freeze again.
> > >
> > > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > > ---
> > > fs/super.c | 27 +++++++++++++++++++++++++--
> > > 1 file changed, 25 insertions(+), 2 deletions(-)
> > >
> > >
> > > diff --git a/fs/super.c b/fs/super.c
> > > index 36adccecc828..151e0eeff2c2 100644
> > > --- a/fs/super.c
> > > +++ b/fs/super.c
> > > @@ -1647,6 +1647,15 @@ static int freeze_frozen_super(struct super_block *sb, enum freeze_holder who)
> > > return 0;
> > > }
> > >
> > > +static void wait_for_partially_frozen(struct super_block *sb)
> > > +{
> > > + up_write(&sb->s_umount);
> > > + wait_var_event(&sb->s_writers.frozen,
> > > + sb->s_writers.frozen == SB_UNFROZEN ||
> > > + sb->s_writers.frozen == SB_FREEZE_COMPLETE);
> > > + down_write(&sb->s_umount);
> >
> > Does sb->s_writers.frozen need WRITE_ONCE/READ_ONCE treatment if we want
> > to check it outside of s_umount? Or should we maybe just open code
> > wait_var_event and only drop the lock after checking the variable?
>
> How about something like:
>
> do {
> up_write(&sb->s_umount);
> down_write(&sb->s_umount);
> } while (sb->s_writers.frozen != SB_UNFROZEN &&
> sb->s_writers.frozen != SB_FREEZE_COMPLETE);
>
> so that we always return in either end state of a freezer transition?
Of course as soon as I hit send I realize that no, we don't want to be
cycling s_umount repeatedly even sb->s_writers.frozen hasn't changed.
And maybe we want the wait to be killable too?
static int wait_for_partially_frozen(struct super_block *sb)
{
int ret = 0;
do {
unsigned short old = sb->s_writers.frozen;
up_write(&sb->s_umount);
ret = wait_var_event_killable(&sb->s_writers.frozen,
sb->s_writers.frozen != old);
down_write(&sb->s_umount);
} while (ret == 0 &&
sb->s_writers.frozen != SB_UNFROZEN &&
sb->s_writers.frozen != SB_FREEZE_COMPLETE);
return ret;
}
I'll try this out and report back.
--D
> > > if (sb->s_writers.frozen != SB_UNFROZEN) {
> > > - deactivate_locked_super(sb);
> > > - return -EBUSY;
> > > + if (!try_again) {
> > > + deactivate_locked_super(sb);
> > > + return -EBUSY;
> > > + }
> > > +
> > > + wait_for_partially_frozen(sb);
> > > + try_again = false;
> > > + goto retry;
> >
> > Can you throw in a comment on wait we're only waiting for a partial
> > freeze one here?
>
> I didn't want a thread to get stuck in the retry forever if it always
> loses the race. However, I think any other threads running freeze_super
> will always end at UNFROZEN or COMPLETE; and thaw_super always goes
> straight froM COMPLETE to UNFROZEN, so I think I'll get rid of the retry
> flag logic entirely.
>
> --D
next prev parent reply other threads:[~2023-06-12 18:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-12 3:15 [PATCHSET RFC 0/3] fs: kernel and userspace filesystem freeze Darrick J. Wong
2023-06-12 3:15 ` [PATCH 1/3] fs: distinguish between user initiated freeze and kernel initiated freeze Darrick J. Wong
2023-06-12 3:58 ` Christoph Hellwig
2023-06-12 18:09 ` Darrick J. Wong
2023-06-12 11:08 ` Jan Kara
2023-06-12 11:14 ` Jan Kara
2023-06-12 18:16 ` Darrick J. Wong
2023-06-12 3:15 ` [PATCH 2/3] fs: wait for partially frozen filesystems Darrick J. Wong
2023-06-12 4:01 ` Christoph Hellwig
2023-06-12 18:33 ` Darrick J. Wong
2023-06-12 18:47 ` Darrick J. Wong [this message]
2023-06-12 11:35 ` Jan Kara
2023-06-12 18:36 ` Darrick J. Wong
2023-06-13 7:52 ` Jan Kara
2023-06-12 3:15 ` [PATCH 3/3] fs: Drop wait_unfrozen wait queue Darrick J. Wong
2023-06-12 11:12 ` Jan Kara
-- strict thread matches above, loose matches on Subject: below --
2023-06-16 1:48 [PATCHSET v2 0/3] fs: kernel and userspace filesystem freeze Darrick J. Wong
2023-06-16 1:48 ` [PATCH 2/3] fs: wait for partially frozen filesystems Darrick J. Wong
2023-06-16 2:19 ` Dave Chinner
2023-06-16 5:52 ` Christoph Hellwig
2023-06-16 13:24 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230612184749.GJ11441@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=ruansy.fnst@fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.