From: Jan Kara <jack@suse.cz>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Jan Kara <jack@suse.cz>, 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, 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:46:10 +0200 [thread overview]
Message-ID: <20230607204610.5ai5cleks6qzjal7@quack3> (raw)
In-Reply-To: <20230607163110.GC72224@frogsfrogsfrogs>
On Wed 07-06-23 09:31:10, Darrick J. Wong wrote:
> On Thu, May 25, 2023 at 04:14:30PM +0200, Jan Kara wrote:
> > On Mon 22-05-23 16:42:00, 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.
> > >
> > > --D
> > >
> > > From: Darrick J. Wong <djwong@kernel.org>
> > > Subject: fs: distinguish between user initiated freeze and kernel initiated freeze
> > >
> > > Userspace can freeze a filesystem using the FIFREEZE ioctl or by
> > > suspending the block device; this state persists until userspace thaws
> > > the filesystem with the FITHAW ioctl or resuming the block device.
> > > Since commit 18e9e5104fcd ("Introduce freeze_super and thaw_super for
> > > the fsfreeze ioctl") we only allow the first freeze command to succeed.
> > >
> > > The kernel may decide that it is necessary to freeze a filesystem for
> > > its own internal purposes, such as suspends in progress, filesystem fsck
> > > activities, or quiescing a device prior to removal. Userspace thaw
> > > commands must never break a kernel freeze, and kernel thaw commands
> > > shouldn't undo userspace's freeze command.
> > >
> > > Introduce a couple of freeze holder flags and wire it into the
> > > sb_writers state. One kernel and one userspace freeze are allowed to
> > > coexist at the same time; the filesystem will not thaw until both are
> > > lifted.
> > >
> > > Inspired-by: Luis Chamberlain <mcgrof@kernel.org>
> > > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> >
> > Yes, this is exactly how I'd imagine it. Thanks for writing the patch!
> >
> > I'd just note that this would need rebasing on top of Luis' patches 1 and
> > 2. Also:
> >
> > > + if (sbw->frozen == SB_FREEZE_COMPLETE) {
> > > + switch (who) {
> > > + case FREEZE_HOLDER_KERNEL:
> > > + if (sbw->freeze_holders & FREEZE_HOLDER_KERNEL) {
> > > + /*
> > > + * Kernel freeze already in effect; caller can
> > > + * try again.
> > > + */
> > > + deactivate_locked_super(sb);
> > > + return -EBUSY;
> > > + }
> > > + if (sbw->freeze_holders & FREEZE_HOLDER_USERSPACE) {
> > > + /*
> > > + * Share the freeze state with the userspace
> > > + * freeze already in effect.
> > > + */
> > > + sbw->freeze_holders |= who;
> > > + deactivate_locked_super(sb);
> > > + return 0;
> > > + }
> > > + break;
> > > + case FREEZE_HOLDER_USERSPACE:
> > > + if (sbw->freeze_holders & FREEZE_HOLDER_USERSPACE) {
> > > + /*
> > > + * Userspace freeze already in effect; tell
> > > + * the caller we're busy.
> > > + */
> > > + deactivate_locked_super(sb);
> > > + return -EBUSY;
> > > + }
> > > + if (sbw->freeze_holders & FREEZE_HOLDER_KERNEL) {
> > > + /*
> > > + * Share the freeze state with the kernel
> > > + * freeze already in effect.
> > > + */
> > > + sbw->freeze_holders |= who;
> > > + deactivate_locked_super(sb);
> > > + return 0;
> > > + }
> > > + break;
> > > + default:
> > > + BUG();
> > > + deactivate_locked_super(sb);
> > > + return -EINVAL;
> > > + }
> > > + }
> >
> > Can't this be simplified to:
> >
> > BUG_ON(who & ~(FREEZE_HOLDER_USERSPACE | FREEZE_HOLDER_KERNEL));
> > BUG_ON(!(!(who & FREEZE_HOLDER_USERSPACE) ^
> > !(who & FREEZE_HOLDER_KERNEL)));
> > retry:
> > if (sb->s_writers.freeze_holders & who)
> > return -EBUSY;
> > /* Already frozen by someone else? */
> > if (sb->s_writers.freeze_holders & ~who) {
> > sb->s_writers.freeze_holders |= who;
> > return 0;
> > }
> >
> > Now the only remaining issue with the code is that the two different
> > holders can be attempting to freeze the filesystem at once and in that case
> > one of them has to wait for the other one instead of returning -EBUSY as
> > would happen currently. This can happen because we temporarily drop
> > s_umount in freeze_super() due to lock ordering issues. I think we could
> > do something like:
> >
> > if (!sb_unfrozen(sb)) {
> > up_write(&sb->s_umount);
> > wait_var_event(&sb->s_writers.frozen,
> > sb_unfrozen(sb) || sb_frozen(sb));
> > down_write(&sb->s_umount);
> > goto retry;
> > }
> >
> > and then sprinkle wake_up_var(&sb->s_writers.frozen) at appropriate places
> > in freeze_super().
>
> If we implemented this behavior change, it ought to be a separate patch.
>
> For the case where the kernel is freezing the fs and userspace wants to
> start freezing the fs, we could make userspace wait and then share the
> kernel freeze.
Yes.
> For any case where the fs is !unfrozen and the kernel wants to start
> freezing the fs, I think I'd rather return EBUSY immediately and let the
> caller decide to wait and/or call back.
Possibly, although I thought that if userspace has frozen the fs and kernel
wants to freeze, we want to return success? At least that was what I think
your patches were doing. And then I don't see the point why we should be
returning EBUSY if userspace is in the middle of the freeze. So what's the
intended semantics?
> For the case where one userspace thread is freezing the fs and another
> userspace thread wants to start freezing the fs, I think the current
> behavior of returning EBUSY immediately is ok.
Yes.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2023-06-07 20:46 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 [this message]
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
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=20230607204610.5ai5cleks6qzjal7@quack3 \
--to=jack@suse.cz \
--cc=bvanassche@acm.org \
--cc=da.gomez@samsung.com \
--cc=djwong@kernel.org \
--cc=ebiederm@xmission.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--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;
as well as URLs for NNTP newsgroup(s).