From: Christoph Hellwig <hch@infradead.org>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
hch@infradead.org, sandeen@sandeen.net, song@kernel.org,
rafael@kernel.org, gregkh@linuxfoundation.org,
viro@zeniv.linux.org.uk, jack@suse.cz, jikos@kernel.org,
bvanassche@acm.org, ebiederm@xmission.com, mchehab@kernel.org,
keescook@chromium.org, p.raghav@samsung.com,
da.gomez@samsung.com, linux-fsdevel@vger.kernel.org,
kernel@tuxforce.de, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/6] fs: distinguish between user initiated freeze and kernel initiated freeze
Date: Wed, 7 Jun 2023 22:24:32 -0700 [thread overview]
Message-ID: <ZIFmEGdJ4CCbS1B3@infradead.org> (raw)
In-Reply-To: <20230522234200.GC11598@frogsfrogsfrogs>
On Mon, May 22, 2023 at 04:42:00PM -0700, Darrick J. Wong wrote:
> How about this as an alternative patch? Kernel and userspace freeze
> state are stored in s_writers; each type cannot block the other (though
> you still can't have nested kernel or userspace freezes); and the freeze
> is maintained until /both/ freeze types are dropped.
>
> AFAICT this should work for the two other usecases (quiescing pagefaults
> for fsdax pmem pre-removal; and freezing fses during suspend) besides
> online fsck for xfs.
I think this is fundamentally the right thing. Can you send this as
a standalone thread in a separate thread to make it sure it gets
expedited?
> -static int thaw_super_locked(struct super_block *sb);
> +static int thaw_super_locked(struct super_block *sb, unsigned short who);
Is the unsigned short really worth it? Even if it's just two values
I'd also go for a __bitwise type to get the typechecking as that tends
to help a lot goind down the road.
> /**
> - * freeze_super - lock the filesystem and force it into a consistent state
> + * __freeze_super - lock the filesystem and force it into a consistent state
> * @sb: the super to lock
> + * @who: FREEZE_HOLDER_USERSPACE if userspace wants to freeze the fs;
> + * FREEZE_HOLDER_KERNEL if the kernel wants to freeze it
> *
> * Syncs the super to make sure the filesystem is consistent and calls the fs's
> - * freeze_fs. Subsequent calls to this without first thawing the fs will return
> + * freeze_fs. Subsequent calls to this without first thawing the fs may return
> * -EBUSY.
> *
> + * The @who argument distinguishes between the kernel and userspace trying to
> + * freeze the filesystem. Although there cannot be multiple kernel freezes or
> + * multiple userspace freezes in effect at any given time, the kernel and
> + * userspace can both hold a filesystem frozen. The filesystem remains frozen
> + * until there are no kernel or userspace freezes in effect.
> + *
> * During this function, sb->s_writers.frozen goes through these values:
> *
> * SB_UNFROZEN: File system is normal, all writes progress as usual.
> @@ -1668,12 +1676,61 @@ static void sb_freeze_unlock(struct super_block *sb, int level)
> *
> * sb->s_writers.frozen is protected by sb->s_umount.
> */
There's really no point in having a kerneldoc for a static function.
Either this moves to the actual exported functions, or it should
become a normal non-kerneldoc comment. But I'm not even sre this split
makes much sense to start with. I'd just add a the who argument
to freeze_super given that we have only very few callers anyway,
and it is way easier to follow than thse rappers hardoding the argument.
> +static int __freeze_super(struct super_block *sb, unsigned short who)
> {
> + struct sb_writers *sbw = &sb->s_writers;
> int ret;
>
> atomic_inc(&sb->s_active);
> down_write(&sb->s_umount);
> +
> + if (sbw->frozen == SB_FREEZE_COMPLETE) {
> + switch (who) {
Nit, but maybe split evetything inside this branch into a
freeze_frozen_super helper?
> +static int thaw_super_locked(struct super_block *sb, unsigned short who)
> +{
> + struct sb_writers *sbw = &sb->s_writers;
> int error;
>
> + if (sbw->frozen == SB_FREEZE_COMPLETE) {
> + switch (who) {
> + case FREEZE_HOLDER_KERNEL:
> + if (!(sbw->freeze_holders & FREEZE_HOLDER_KERNEL)) {
> + /* Caller doesn't hold a kernel freeze. */
> + up_write(&sb->s_umount);
> + return -EINVAL;
> + }
> + if (sbw->freeze_holders & FREEZE_HOLDER_USERSPACE) {
> + /*
> + * We were sharing the freeze with userspace,
> + * so drop the userspace freeze but exit
> + * without unfreezing.
> + */
> + sbw->freeze_holders &= ~who;
> + up_write(&sb->s_umount);
> + return 0;
> + }
> + break;
> + case FREEZE_HOLDER_USERSPACE:
> + if (!(sbw->freeze_holders & FREEZE_HOLDER_USERSPACE)) {
> + /* Caller doesn't hold a userspace freeze. */
> + up_write(&sb->s_umount);
> + return -EINVAL;
> + }
> + if (sbw->freeze_holders & FREEZE_HOLDER_KERNEL) {
> + /*
> + * We were sharing the freeze with the kernel,
> + * so drop the kernel freeze but exit without
> + * unfreezing.
> + */
> + sbw->freeze_holders &= ~who;
> + up_write(&sb->s_umount);
> + return 0;
> + }
> + break;
> + default:
> + BUG();
> + up_write(&sb->s_umount);
> + return -EINVAL;
> + }
To me this screams for another 'is_partial_thaw' or so helper, whith
which we could doe something like:
if (sbw->frozen != SB_FREEZE_COMPLETE) {
ret = -EINVAL;
goto out_unlock;
}
ret = is_partial_thaw(sb, who);
if (ret) {
if (ret == 1) {
sbw->freeze_holders &= ~who;
ret = 0
}
goto out_unlock;
}
Btw, same comment about the wrappers as on the freeze side.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2023-06-08 5:24 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-08 1:17 [PATCH 0/6] vfs: provide automatic kernel freeze / resume Luis Chamberlain
2023-05-08 1:17 ` [PATCH 1/6] fs: unify locking semantics for fs freeze / thaw Luis Chamberlain
2023-05-18 5:32 ` Darrick J. Wong
2023-05-25 12:17 ` Jan Kara
2023-06-08 5:01 ` Christoph Hellwig
2023-06-08 19:55 ` Luis Chamberlain
2023-05-08 1:17 ` [PATCH 2/6] fs: add frozen sb state helpers Luis Chamberlain
2023-05-25 12:19 ` Jan Kara
2023-06-08 5:05 ` Christoph Hellwig
2023-06-08 15:05 ` Darrick J. Wong
2023-05-08 1:17 ` [PATCH 3/6] fs: distinguish between user initiated freeze and kernel initiated freeze Luis Chamberlain
2023-05-16 15:23 ` Darrick J. Wong
2023-05-22 23:42 ` Darrick J. Wong
2023-05-25 14:14 ` Jan Kara
2023-06-06 17:19 ` Darrick J. Wong
2023-06-07 9:22 ` Jan Kara
2023-06-07 14:50 ` Darrick J. Wong
2023-06-08 20:30 ` Luis Chamberlain
2023-06-07 16:31 ` Darrick J. Wong
2023-06-07 20:46 ` Jan Kara
2023-06-08 18:58 ` Darrick J. Wong
2023-06-08 5:29 ` Christoph Hellwig
2023-06-08 9:11 ` Jan Kara
2023-06-08 18:16 ` Darrick J. Wong
2023-06-08 5:24 ` Christoph Hellwig [this message]
2023-06-08 18:15 ` Darrick J. Wong
2023-06-08 20:26 ` Luis Chamberlain
2023-06-08 21:10 ` Darrick J. Wong
2023-05-08 1:17 ` [PATCH 4/6] fs: move !SB_BORN check early on freeze and add for thaw Luis Chamberlain
2023-05-08 1:17 ` [PATCH 5/6] fs: add iterate_supers_excl() and iterate_supers_reverse_excl() Luis Chamberlain
2023-05-08 1:17 ` [PATCH 6/6] fs: add automatic kernel fs freeze / thaw and remove kthread freezing Luis Chamberlain
2023-05-09 1:20 ` Dave Chinner
2023-05-16 15:17 ` Darrick J. Wong
2023-05-08 1:21 ` [PATCH 0/6] vfs: provide automatic kernel freeze / resume Luis Chamberlain
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=ZIFmEGdJ4CCbS1B3@infradead.org \
--to=hch@infradead.org \
--cc=bvanassche@acm.org \
--cc=da.gomez@samsung.com \
--cc=djwong@kernel.org \
--cc=ebiederm@xmission.com \
--cc=gregkh@linuxfoundation.org \
--cc=jack@suse.cz \
--cc=jikos@kernel.org \
--cc=keescook@chromium.org \
--cc=kernel@tuxforce.de \
--cc=kexec@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=mchehab@kernel.org \
--cc=p.raghav@samsung.com \
--cc=rafael@kernel.org \
--cc=sandeen@sandeen.net \
--cc=song@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox