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@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
