From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Luis Chamberlain <mcgrof@kernel.org>,
jack@suse.cz, hch@infradead.org, david@fromorbit.com,
rafael@kernel.org, djwong@kernel.org, pavel@kernel.org,
song@kernel.org
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
gost.dev@samsung.com
Subject: Re: [RFC 3/6] fs: add automatic kernel fs freeze / thaw and remove kthread freezing
Date: Wed, 26 Mar 2025 07:53:10 -0400 [thread overview]
Message-ID: <827c1ff030dd3b208e7a14be63160703b67e7031.camel@HansenPartnership.com> (raw)
In-Reply-To: <20250326112220.1988619-4-mcgrof@kernel.org>
On Wed, 2025-03-26 at 04:22 -0700, Luis Chamberlain wrote:
> Add support to automatically handle freezing and thawing filesystems
> during the kernel's suspend/resume cycle.
>
> This is needed so that we properly really stop IO in flight without
> races after userspace has been frozen. Without this we rely on
> kthread freezing and its semantics are loose and error prone.
> For instance, even though a kthread may use try_to_freeze() and end
> up being frozen we have no way of being sure that everything that
> has been spawned asynchronously from it (such as timers) have also
> been stopped as well.
>
> A long term advantage of also adding filesystem freeze / thawing
> supporting during suspend / hibernation is that long term we may
> be able to eventually drop the kernel's thread freezing completely
> as it was originally added to stop disk IO in flight as we hibernate
> or suspend.
>
> This does not remove the superfluous freezer calls on all
> filesystems.
> Each filesystem must remove all the kthread freezer stuff and peg
> the fs_type flags as supporting auto-freezing with the FS_AUTOFREEZE
> flag.
>
> Subsequent patches remove the kthread freezer usage from each
> filesystem, one at a time to make all this work bisectable.
> Once all filesystems remove the usage of the kthread freezer we
> can remove the FS_AUTOFREEZE flag.
>
> Reviewed-by: Jan Kara <jack@suse.cz>
> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
> ---
> fs/super.c | 50
> ++++++++++++++++++++++++++++++++++++++++++
> include/linux/fs.h | 14 ++++++++++++
> kernel/power/process.c | 15 ++++++++++++-
> 3 files changed, 78 insertions(+), 1 deletion(-)
>
> diff --git a/fs/super.c b/fs/super.c
> index 9995546cf159..7428f0b2251c 100644
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -2279,3 +2279,53 @@ int sb_init_dio_done_wq(struct super_block
> *sb)
> return 0;
> }
> EXPORT_SYMBOL_GPL(sb_init_dio_done_wq);
> +
> +#ifdef CONFIG_PM_SLEEP
> +static bool super_should_freeze(struct super_block *sb)
> +{
> + if (!(sb->s_type->fs_flags & FS_AUTOFREEZE))
> + return false;
> + /*
> + * We don't freeze virtual filesystems, we skip those
> filesystems with
> + * no backing device.
> + */
> + if (sb->s_bdi == &noop_backing_dev_info)
> + return false;
This logic won't work for me because efivarfs is a pseudofilesystem and
will have a noop bdi (or simply a null s_bdev, which is easier to check
for). I was thinking of allowing freeze/thaw to continue for a s_bdev
== NULL filesystem if it provided a freeze or thaw callback, which will
cover efivarfs.
> +
> + return true;
> +}
> +
> +int fs_suspend_freeze_sb(struct super_block *sb, void *priv)
> +{
> + int error = 0;
> +
> + if (!super_should_freeze(sb))
> + goto out;
> +
> + pr_info("%s (%s): freezing\n", sb->s_type->name, sb->s_id);
> +
> + error = freeze_super(sb, false);
This is actually not wholly correct now. If the fs provides a sb-
>freeze() method, you should use that instead of freeze_super() ... see
how fs_bdev_freeze() is doing it.
Additionally, the first thing freeze_super() does is take the
superblock lock exclusively. Since you've already taken it exclusively
in your iterate super, how does this not deadlock?
You also need to handle the hibernate deadlock I ran into where a
process (and some of the systemd processes are very fast at doing this)
touches the filesystem and gets blocked on uninterruptible wait before
the remainder of freeze_processes() runs. Once a task is
uninterruptible hibernate fails. I came up with a simplistic solution:
https://lore.kernel.org/linux-fsdevel/1af829aa7a65eb5ebc0614a00f7019615ed0f62b.camel@HansenPartnership.com/
But there should probably be a freezable percpu_rwsem that
sb_write_started() can use to get these semantics rather than making
every use of percpu_rwsem freezable.
Regards,
James
next prev parent reply other threads:[~2025-03-26 11:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-26 11:22 [RFC 0/6] fs: automatic kernel fs freeze / thaw Luis Chamberlain
2025-03-26 11:22 ` [RFC 1/6] fs: add frozen sb state helpers Luis Chamberlain
2025-03-26 11:22 ` [RFC 2/6] fs: add iterate_supers_excl() and iterate_supers_reverse_excl() Luis Chamberlain
2025-03-26 13:17 ` Christian Brauner
2025-03-26 11:22 ` [RFC 3/6] fs: add automatic kernel fs freeze / thaw and remove kthread freezing Luis Chamberlain
2025-03-26 11:53 ` James Bottomley [this message]
2025-03-26 14:09 ` Christian Brauner
2025-03-26 14:37 ` James Bottomley
2025-03-26 11:22 ` [RFC 4/6] ext4: replace kthread freezing with auto fs freezing Luis Chamberlain
2025-03-26 17:57 ` Jan Kara
2025-03-26 11:22 ` [RFC 5/6] btrfs: " Luis Chamberlain
2025-03-26 11:22 ` [RFC 6/6] xfs: " Luis Chamberlain
2025-03-26 11:42 ` [RFC 0/6] fs: automatic kernel fs freeze / thaw Luis Chamberlain
2025-03-26 12:27 ` James Bottomley
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=827c1ff030dd3b208e7a14be63160703b67e7031.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=gost.dev@samsung.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=pavel@kernel.org \
--cc=rafael@kernel.org \
--cc=song@kernel.org \
/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
all inboxes | Powered by JetHome®