From: "Darrick J. Wong" <djwong@kernel.org>
To: Dave Chinner <david@fromorbit.com>
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 6/6] fs: add automatic kernel fs freeze / thaw and remove kthread freezing
Date: Tue, 16 May 2023 08:17:18 -0700 [thread overview]
Message-ID: <20230516151718.GP858815@frogsfrogsfrogs> (raw)
In-Reply-To: <20230509012013.GD2651828@dread.disaster.area>
On Tue, May 09, 2023 at 11:20:13AM +1000, Dave Chinner wrote:
> On Sun, May 07, 2023 at 06:17:17PM -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/kernel/power/process.c b/kernel/power/process.c
> > index cae81a87cc91..7ca7688f0b5d 100644
> > --- a/kernel/power/process.c
> > +++ b/kernel/power/process.c
> > @@ -140,6 +140,16 @@ int freeze_processes(void)
> >
> > BUG_ON(in_atomic());
> >
> > + pr_info("Freezing filesystems ... ");
> > + error = iterate_supers_reverse_excl(fs_suspend_freeze_sb, NULL);
> > + if (error) {
> > + pr_cont("failed\n");
> > + iterate_supers_excl(fs_suspend_thaw_sb, NULL);
> > + thaw_processes();
> > + return error;
>
> That looks wrong. i.e. if the sb iteration fails to freeze a
> filesystem (for whatever reason) then every userspace frozen
> filesystem will be thawed by this call, right? i.e. it will thaw
> more than just the filesystems frozen by the suspend freeze
> iteration before it failed.
>
> Don't we only want to thaw the superblocks we froze before the
> failure occurred? i.e. the "undo" iteration needs to start from the
> last superblock we successfully froze and then only walk to the tail
> of the list we started from?
I think fs_suspend_thaw_sb calls thaw_super(..., false), which will not
undo a userspace freeze. So strictly speaking the answer to your
question is (AFAICT) "no it won't"
That said, I read this and also had a raised-eyebrow moment -- we
shouldn't (un?)touch superblocks that fs_suspend_freeze_sb didn't touch
in the first place.
I wonder if we should be using that NULL parameter to keep track of the
last super that fs_suspend_freeze_sb didn't fail on?
--D
> > + }
> > + pr_cont("done.\n");
> > +
> > /*
> > * Now that the whole userspace is frozen we need to disable
> > * the OOM killer to disallow any further interference with
> > @@ -149,8 +159,10 @@ int freeze_processes(void)
> > if (!error && !oom_killer_disable(msecs_to_jiffies(freeze_timeout_msecs)))
> > error = -EBUSY;
> >
> > - if (error)
> > + if (error) {
> > + iterate_supers_excl(fs_suspend_thaw_sb, NULL);
> > thaw_processes();
> > + }
>
> Does this also have the same problem? i.e. if fs_suspend_freeze_sb()
> skips over superblocks that are already userspace frozen without any
> error, then this will incorrectly thaw those userspace frozen
> filesystems.
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: "Darrick J. Wong" <djwong@kernel.org>
To: Dave Chinner <david@fromorbit.com>
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 6/6] fs: add automatic kernel fs freeze / thaw and remove kthread freezing
Date: Tue, 16 May 2023 08:17:18 -0700 [thread overview]
Message-ID: <20230516151718.GP858815@frogsfrogsfrogs> (raw)
In-Reply-To: <20230509012013.GD2651828@dread.disaster.area>
On Tue, May 09, 2023 at 11:20:13AM +1000, Dave Chinner wrote:
> On Sun, May 07, 2023 at 06:17:17PM -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/kernel/power/process.c b/kernel/power/process.c
> > index cae81a87cc91..7ca7688f0b5d 100644
> > --- a/kernel/power/process.c
> > +++ b/kernel/power/process.c
> > @@ -140,6 +140,16 @@ int freeze_processes(void)
> >
> > BUG_ON(in_atomic());
> >
> > + pr_info("Freezing filesystems ... ");
> > + error = iterate_supers_reverse_excl(fs_suspend_freeze_sb, NULL);
> > + if (error) {
> > + pr_cont("failed\n");
> > + iterate_supers_excl(fs_suspend_thaw_sb, NULL);
> > + thaw_processes();
> > + return error;
>
> That looks wrong. i.e. if the sb iteration fails to freeze a
> filesystem (for whatever reason) then every userspace frozen
> filesystem will be thawed by this call, right? i.e. it will thaw
> more than just the filesystems frozen by the suspend freeze
> iteration before it failed.
>
> Don't we only want to thaw the superblocks we froze before the
> failure occurred? i.e. the "undo" iteration needs to start from the
> last superblock we successfully froze and then only walk to the tail
> of the list we started from?
I think fs_suspend_thaw_sb calls thaw_super(..., false), which will not
undo a userspace freeze. So strictly speaking the answer to your
question is (AFAICT) "no it won't"
That said, I read this and also had a raised-eyebrow moment -- we
shouldn't (un?)touch superblocks that fs_suspend_freeze_sb didn't touch
in the first place.
I wonder if we should be using that NULL parameter to keep track of the
last super that fs_suspend_freeze_sb didn't fail on?
--D
> > + }
> > + pr_cont("done.\n");
> > +
> > /*
> > * Now that the whole userspace is frozen we need to disable
> > * the OOM killer to disallow any further interference with
> > @@ -149,8 +159,10 @@ int freeze_processes(void)
> > if (!error && !oom_killer_disable(msecs_to_jiffies(freeze_timeout_msecs)))
> > error = -EBUSY;
> >
> > - if (error)
> > + if (error) {
> > + iterate_supers_excl(fs_suspend_thaw_sb, NULL);
> > thaw_processes();
> > + }
>
> Does this also have the same problem? i.e. if fs_suspend_freeze_sb()
> skips over superblocks that are already userspace frozen without any
> error, then this will incorrectly thaw those userspace frozen
> filesystems.
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
next prev parent reply other threads:[~2023-05-16 15:17 UTC|newest]
Thread overview: 70+ 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 ` Luis Chamberlain
2023-05-08 1:17 ` [PATCH 1/6] fs: unify locking semantics for fs freeze / thaw Luis Chamberlain
2023-05-08 1:17 ` Luis Chamberlain
2023-05-12 6:00 ` kernel test robot
2023-05-12 23:54 ` kernel test robot
2023-05-18 5:32 ` Darrick J. Wong
2023-05-18 5:32 ` Darrick J. Wong
2023-05-25 12:17 ` Jan Kara
2023-05-25 12:17 ` Jan Kara
2023-06-08 5:01 ` Christoph Hellwig
2023-06-08 5:01 ` Christoph Hellwig
2023-06-08 19:55 ` Luis Chamberlain
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-08 1:17 ` Luis Chamberlain
2023-05-25 12:19 ` Jan Kara
2023-05-25 12:19 ` Jan Kara
2023-06-08 5:05 ` Christoph Hellwig
2023-06-08 5:05 ` Christoph Hellwig
2023-06-08 15:05 ` Darrick J. Wong
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-08 1:17 ` Luis Chamberlain
2023-05-16 15:23 ` Darrick J. Wong
2023-05-16 15:23 ` Darrick J. Wong
2023-05-22 23:42 ` Darrick J. Wong
2023-05-22 23:42 ` Darrick J. Wong
2023-05-25 14:14 ` Jan Kara
2023-05-25 14:14 ` Jan Kara
2023-06-06 17:19 ` Darrick J. Wong
2023-06-06 17:19 ` Darrick J. Wong
2023-06-07 9:22 ` Jan Kara
2023-06-07 9:22 ` Jan Kara
2023-06-07 14:50 ` Darrick J. Wong
2023-06-07 14:50 ` Darrick J. Wong
2023-06-08 20:30 ` Luis Chamberlain
2023-06-08 20:30 ` Luis Chamberlain
2023-06-07 16:31 ` Darrick J. Wong
2023-06-07 16:31 ` Darrick J. Wong
2023-06-07 20:46 ` Jan Kara
2023-06-07 20:46 ` Jan Kara
2023-06-08 18:58 ` Darrick J. Wong
2023-06-08 18:58 ` Darrick J. Wong
2023-06-08 5:29 ` Christoph Hellwig
2023-06-08 5:29 ` Christoph Hellwig
2023-06-08 9:11 ` Jan Kara
2023-06-08 9:11 ` Jan Kara
2023-06-08 18:16 ` Darrick J. Wong
2023-06-08 18:16 ` Darrick J. Wong
2023-06-08 5:24 ` Christoph Hellwig
2023-06-08 5:24 ` Christoph Hellwig
2023-06-08 18:15 ` Darrick J. Wong
2023-06-08 18:15 ` Darrick J. Wong
2023-06-08 20:26 ` Luis Chamberlain
2023-06-08 20:26 ` Luis Chamberlain
2023-06-08 21:10 ` Darrick J. Wong
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 ` 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 ` 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-08 1:17 ` Luis Chamberlain
2023-05-09 1:20 ` Dave Chinner
2023-05-09 1:20 ` Dave Chinner
2023-05-16 15:17 ` Darrick J. Wong [this message]
2023-05-16 15:17 ` Darrick J. Wong
2023-05-08 1:21 ` [PATCH 0/6] vfs: provide automatic kernel freeze / resume Luis Chamberlain
2023-05-08 1:21 ` 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=20230516151718.GP858815@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=bvanassche@acm.org \
--cc=da.gomez@samsung.com \
--cc=david@fromorbit.com \
--cc=ebiederm@xmission.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.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 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.