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
next prev parent 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: linkBe 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.