Re: [Ksummit-discuss] [TECH TOPIC] giving freezer well-defined semantics

["Rafael J. Wysocki" <rjw@rjwysocki.net>]

On Tuesday, July 07, 2015 11:13:01 PM Jiri Kosina wrote:
> On Tue, 7 Jul 2015, Rafael J. Wysocki wrote:
> 
> > > Currently, the freezer has rather random semantics and there is no 
> > > rigorous definition that would provide clear guidance which kernel threads 
> > > should be freezable (and what rules they have to follow if they are).
> > 
> > That's with respect to kernel threads, right?
> 
> Yeah, sorry for not being verbose enough. I have been buried in kthread 
> interactions with the rest of the kernel for too long, so my world view is 
> now a bit distorted.
> 
> Yes, this is purely related to try_to_freeze() in !PF_NOFREEZE kernel 
> threads.
> 
> > The primary purpose of the freezer is to get user space out of the way
> > and at least in principle there should be no fundamental need to freeze
> > any kernel threads.
> 
> Except those which are needed for hibernation image I/O.

I don't quite see why there's a need to freeze those particular ones.

OK, it is necessary to ensure that the contents of the image will be consistent
with the state of filesystems on the storage media, so everything that may
change that state should be "frozen" before the image is created, but "frozen"
in terms of "no persistent state changes from now on" rather than in terms of
"no forward progress from now on".

Thanks,
Rafael