From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <rjw@rjwysocki.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1B678B13
	for <ksummit-discuss@lists.linuxfoundation.org>;
	Wed,  8 Jul 2015 21:28:42 +0000 (UTC)
Received: from v094114.home.net.pl (v094114.home.net.pl [79.96.170.134])
	by smtp1.linuxfoundation.org (Postfix) with SMTP id 74CE6F7
	for <ksummit-discuss@lists.linuxfoundation.org>;
	Wed,  8 Jul 2015 21:28:41 +0000 (UTC)
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Jiri Kosina <jkosina@suse.com>
Date: Wed, 08 Jul 2015 23:55:09 +0200
Message-ID: <119701572.LaCIUMEEyV@vostro.rjw.lan>
In-Reply-To: <alpine.LNX.2.00.1507081015120.10183@pobox.suse.cz>
References: <alpine.LNX.2.00.1507071340480.10183@pobox.suse.cz>
	<9412727.0bKgPF9YKr@vostro.rjw.lan>
	<alpine.LNX.2.00.1507081015120.10183@pobox.suse.cz>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="utf-8"
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [TECH TOPIC] giving freezer well-defined
	semantics
List-Id: <ksummit-discuss.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/ksummit-discuss>,
	<mailto:ksummit-discuss-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/ksummit-discuss/>
List-Post: <mailto:ksummit-discuss@lists.linuxfoundation.org>
List-Help: <mailto:ksummit-discuss-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss>,
	<mailto:ksummit-discuss-request@lists.linuxfoundation.org?subject=subscribe>

On Wednesday, July 08, 2015 10:16:39 AM Jiri Kosina wrote:
> On Wed, 8 Jul 2015, Rafael J. Wysocki wrote:
> 
> > 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".
> 
> Yeah. So again, why do we even have freezer for so many kernel threads at 
> all? :)

Well, one reason may be that we've never grown a decent mechanism for freezing
filesystems (as in "no persistent state changes from now on") and people try to
make up for that by stopping things if they can (but in the kernel space that's
inherently racy).

There also are places where it has been forever and no one is sure what happens
after it's been dropped from there.

And there are places where it is used to provide specific guaranees (like in
the runtime PM framework), but might be replaced with a different mechanism.

Essentially, as I said above, the freezer is only really useful for things
requiring the "no forward progress from now on" rule.  There are things like
that in the kernel too, but I bet there are not too many of them.

Thanks,
Rafael