All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: Jan Kara <jack@suse.cz>,
	hch@infradead.org, song@kernel.org, rafael@kernel.org,
	gregkh@linuxfoundation.org, viro@zeniv.linux.org.uk,
	bvanassche@acm.org, ebiederm@xmission.com, mchehab@kernel.org,
	keescook@chromium.org, p.raghav@samsung.com,
	linux-fsdevel@vger.kernel.org, kernel@tuxforce.de,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	xfs <linux-xfs@vger.kernel.org>
Subject: Re: [RFC v3 03/24] fs: distinguish between user initiated freeze and kernel initiated freeze
Date: Mon, 22 May 2023 17:33:05 -0700	[thread overview]
Message-ID: <20230523003305.GD11620@frogsfrogsfrogs> (raw)
In-Reply-To: <ZFckQz3udm48kprc@bombadil.infradead.org>

On Sat, May 06, 2023 at 09:08:35PM -0700, Luis Chamberlain wrote:
> On Wed, Jan 18, 2023 at 10:28:12AM +0100, Jan Kara wrote:
> > On Tue 17-01-23 18:25:40, Darrick J. Wong wrote:
> > > [add linux-xfs to cc on this one]
> > > 
> > > On Fri, Jan 13, 2023 at 04:33:48PM -0800, Luis Chamberlain wrote:
> > > > Userspace can initiate a freeze call using ioctls. If the kernel decides
> > > > to freeze a filesystem later it must be able to distinguish if userspace
> > > > had initiated the freeze, so that it does not unfreeze it later
> > > > automatically on resume.
> > > 
> > > Hm.  Zooming out a bit here, I want to think about how kernel freezes
> > > should behave...
> > > 
> > > > Likewise if the kernel is initiating a freeze on its own it should *not*
> > > > fail to freeze a filesystem if a user had already frozen it on our behalf.
> > > 
> > > ...because kernel freezes can absorb an existing userspace freeze.  Does
> > > that mean that userspace should be prevented from undoing a kernel
> > > freeze?  Even in that absorption case?
> > > 
> > > Also, should we permit multiple kernel freezes of the same fs at the
> > > same time?  And if we do allow that, would they nest like freeze used to
> > > do?
> > > 
> > > (My suggestions here are 'yes', 'yes', and '**** no'.)
> > 
> > Yeah, makes sense to me. So I think the mental model to make things safe
> > is that there are two flags - frozen_by_user, frozen_by_kernel - and the
> > superblock is kept frozen as long as either of these is set.
> 
> Makes sense to me.

Just sent a patch for this, sorry it took a couple of weeks while I was
busy merging in parent pointers...

--D

>   Luis

_______________________________________________
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: Luis Chamberlain <mcgrof@kernel.org>
Cc: Jan Kara <jack@suse.cz>,
	hch@infradead.org, song@kernel.org, rafael@kernel.org,
	gregkh@linuxfoundation.org, viro@zeniv.linux.org.uk,
	bvanassche@acm.org, ebiederm@xmission.com, mchehab@kernel.org,
	keescook@chromium.org, p.raghav@samsung.com,
	linux-fsdevel@vger.kernel.org, kernel@tuxforce.de,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	xfs <linux-xfs@vger.kernel.org>
Subject: Re: [RFC v3 03/24] fs: distinguish between user initiated freeze and kernel initiated freeze
Date: Mon, 22 May 2023 17:33:05 -0700	[thread overview]
Message-ID: <20230523003305.GD11620@frogsfrogsfrogs> (raw)
In-Reply-To: <ZFckQz3udm48kprc@bombadil.infradead.org>

On Sat, May 06, 2023 at 09:08:35PM -0700, Luis Chamberlain wrote:
> On Wed, Jan 18, 2023 at 10:28:12AM +0100, Jan Kara wrote:
> > On Tue 17-01-23 18:25:40, Darrick J. Wong wrote:
> > > [add linux-xfs to cc on this one]
> > > 
> > > On Fri, Jan 13, 2023 at 04:33:48PM -0800, Luis Chamberlain wrote:
> > > > Userspace can initiate a freeze call using ioctls. If the kernel decides
> > > > to freeze a filesystem later it must be able to distinguish if userspace
> > > > had initiated the freeze, so that it does not unfreeze it later
> > > > automatically on resume.
> > > 
> > > Hm.  Zooming out a bit here, I want to think about how kernel freezes
> > > should behave...
> > > 
> > > > Likewise if the kernel is initiating a freeze on its own it should *not*
> > > > fail to freeze a filesystem if a user had already frozen it on our behalf.
> > > 
> > > ...because kernel freezes can absorb an existing userspace freeze.  Does
> > > that mean that userspace should be prevented from undoing a kernel
> > > freeze?  Even in that absorption case?
> > > 
> > > Also, should we permit multiple kernel freezes of the same fs at the
> > > same time?  And if we do allow that, would they nest like freeze used to
> > > do?
> > > 
> > > (My suggestions here are 'yes', 'yes', and '**** no'.)
> > 
> > Yeah, makes sense to me. So I think the mental model to make things safe
> > is that there are two flags - frozen_by_user, frozen_by_kernel - and the
> > superblock is kept frozen as long as either of these is set.
> 
> Makes sense to me.

Just sent a patch for this, sorry it took a couple of weeks while I was
busy merging in parent pointers...

--D

>   Luis

  reply	other threads:[~2023-05-23  0:33 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-14  0:33 [RFC v3 00/24] vfs: provide automatic kernel freeze / resume Luis Chamberlain
2023-01-14  0:33 ` Luis Chamberlain
2023-01-14  0:33 ` [RFC v3 01/24] fs: unify locking semantics for fs freeze / thaw Luis Chamberlain
2023-01-14  0:33   ` Luis Chamberlain
2023-01-16 15:14   ` Jan Kara
2023-01-16 15:14     ` Jan Kara
2023-05-07  3:47     ` Luis Chamberlain
2023-05-07  3:47       ` Luis Chamberlain
2023-01-14  0:33 ` [RFC v3 02/24] fs: add frozen sb state helpers Luis Chamberlain
2023-01-14  0:33   ` Luis Chamberlain
2023-01-16 16:11   ` Jan Kara
2023-01-16 16:11     ` Jan Kara
2023-01-14  0:33 ` [RFC v3 03/24] fs: distinguish between user initiated freeze and kernel initiated freeze Luis Chamberlain
2023-01-14  0:33   ` Luis Chamberlain
2023-01-16 16:10   ` Jan Kara
2023-01-16 16:10     ` Jan Kara
2023-01-18  2:25   ` Darrick J. Wong
2023-01-18  2:25     ` Darrick J. Wong
2023-01-18  9:28     ` Jan Kara
2023-01-18  9:28       ` Jan Kara
2023-05-07  4:08       ` Luis Chamberlain
2023-05-07  4:08         ` Luis Chamberlain
2023-05-23  0:33         ` Darrick J. Wong [this message]
2023-05-23  0:33           ` Darrick J. Wong
2023-01-14  0:33 ` [RFC v3 04/24] fs: add iterate_supers_excl() and iterate_supers_reverse_excl() Luis Chamberlain
2023-01-14  0:33   ` Luis Chamberlain
2023-01-14  0:33 ` [RFC v3 05/24] fs: add automatic kernel fs freeze / thaw and remove kthread freezing Luis Chamberlain
2023-01-14  0:33   ` Luis Chamberlain
2023-01-14  0:57   ` Luis Chamberlain
2023-01-14  0:57     ` Luis Chamberlain
2023-01-16 16:09   ` Jan Kara
2023-01-16 16:09     ` Jan Kara
2023-02-24  3:08   ` Darrick J. Wong
2023-02-24  3:08     ` Darrick J. Wong
2023-05-07  4:07     ` Luis Chamberlain
2023-05-07  4:07       ` Luis Chamberlain
2023-01-14  0:33 ` [RFC v3 06/24] xfs: replace kthread freezing with auto fs freezing Luis Chamberlain
2023-01-14  0:33   ` Luis Chamberlain
2023-01-14  0:33 ` [RFC v3 07/24] btrfs: " Luis Chamberlain
2023-01-14  0:33   ` Luis Chamberlain
2023-01-14  0:33 ` [RFC v3 08/24] ext4: " Luis Chamberlain
2023-01-14  0:33   ` Luis Chamberlain
2023-01-14  0:33 ` [RFC v3 09/24] f2fs: " Luis Chamberlain
2023-01-14  0:33   ` Luis Chamberlain
2023-01-14  0:33 ` [RFC v3 10/24] cifs: " Luis Chamberlain
2023-01-14  0:33   ` Luis Chamberlain
2023-01-14  0:33 ` [RFC v3 11/24] gfs2: " Luis Chamberlain
2023-01-14  0:33   ` Luis Chamberlain
2023-01-14  0:33 ` [RFC v3 12/24] jfs: " Luis Chamberlain
2023-01-14  0:33   ` Luis Chamberlain
2023-01-14  0:33 ` [RFC v3 13/24] nilfs2: " Luis Chamberlain
2023-01-14  0:33   ` Luis Chamberlain
2023-01-14  0:33 ` [RFC v3 14/24] nfs: " Luis Chamberlain
2023-01-14  0:33   ` Luis Chamberlain
2023-01-14  0:34 ` [RFC v3 15/24] nfsd: " Luis Chamberlain
2023-01-14  0:34   ` Luis Chamberlain
2023-01-14  0:34 ` [RFC v3 16/24] ubifs: " Luis Chamberlain
2023-01-14  0:34   ` Luis Chamberlain
2023-01-14  0:34 ` [RFC v3 17/24] ksmbd: " Luis Chamberlain
2023-01-14  0:34   ` Luis Chamberlain
2023-01-14  0:34 ` [RFC v3 18/24] jffs2: " Luis Chamberlain
2023-01-14  0:34   ` Luis Chamberlain
2023-01-14  0:34 ` [RFC v3 19/24] jbd2: " Luis Chamberlain
2023-01-14  0:34   ` Luis Chamberlain
2023-01-14  0:34 ` [RFC v3 20/24] coredump: drop freezer usage Luis Chamberlain
2023-01-14  0:34   ` Luis Chamberlain
2023-01-14  0:34 ` [RFC v3 21/24] ecryptfs: replace kthread freezing with auto fs freezing Luis Chamberlain
2023-01-14  0:34   ` Luis Chamberlain
2023-01-14  0:34 ` [RFC v3 22/24] fscache: " Luis Chamberlain
2023-01-14  0:34   ` Luis Chamberlain
2023-01-14  0:34 ` [RFC v3 23/24] lockd: " Luis Chamberlain
2023-01-14  0:34   ` Luis Chamberlain
2023-01-14  0:34 ` [RFC v3 24/24] fs: remove FS_AUTOFREEZE Luis Chamberlain
2023-01-14  0:34   ` 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=20230523003305.GD11620@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=bvanassche@acm.org \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --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=linux-xfs@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=mchehab@kernel.org \
    --cc=p.raghav@samsung.com \
    --cc=rafael@kernel.org \
    --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.