From: "Darrick J. Wong" <djwong@kernel.org>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: 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: Thu, 8 Jun 2023 14:10:20 -0700 [thread overview]
Message-ID: <20230608211020.GH72224@frogsfrogsfrogs> (raw)
In-Reply-To: <ZII5awqVCr9IUWtH@bombadil.infradead.org>
On Thu, Jun 08, 2023 at 01:26:19PM -0700, Luis Chamberlain wrote:
> On Mon, May 22, 2023 at 04:42:00PM -0700, Darrick J. Wong wrote:
> > How about this as an alternative patch?
>
> I'm all for it, this is low hanging fruit and I try to get back to it
> as no one else does, so I'm glad someone else is looking and trying too!
>
> Hopefully dropping patch 1 and 2 would help with this.
>
> Comments below.
>
> > 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.
>
> This mix-match stuff is also important to document so we can get
> userspace to understand what is allowed and we get a sense of direction
> written / documented. Without this trying to navigate around this is
> all implied. We may need to adjust things with time for thing we may
> not have considered.
That's captured in the kernledoc for freeze_super, which is no longer
getting cut up into __freeze_super here.
> > -int freeze_super(struct super_block *sb)
> > +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) {
>
> <-- snip -->
>
> > + 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;
>
> I'm thinking some userspace might find this OK so thought maybe
> something like -EALREADY would be better, to then allow userspace
> to decide, however, since userspace would not control the thaw it
> seems like risky business to support that.
It already has to, since we've been returning EBUSY for "fs already
frozen or being frozen" for years.
--D
> Anyway, I'm all for any alternative!
>
> Luis
next prev parent reply other threads:[~2023-06-08 21:10 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
2023-06-08 18:15 ` Darrick J. Wong
2023-06-08 20:26 ` Luis Chamberlain
2023-06-08 21:10 ` Darrick J. Wong [this message]
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=20230608211020.GH72224@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=bvanassche@acm.org \
--cc=da.gomez@samsung.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 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).