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:33:02 -0700 [thread overview]
Message-ID: <20230612183302.GH11441@frogsfrogsfrogs> (raw)
In-Reply-To: <ZIaYrA3Jz5Q75X1P@infradead.org>
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?
> > 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:33 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 [this message]
2023-06-12 18:47 ` Darrick J. Wong
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=20230612183302.GH11441@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.