linux-kernel - Re: [PATCH 0/3] PM, vfs: use filesystem freezing instead of kthread freezer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.1510301121340.1659-100000@iolanthe.rowland.org>
Date:	Fri, 30 Oct 2015 11:29:08 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Jiri Kosina <jikos@...nel.org>
cc:	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Dave Chinner <david@...morbit.com>, Jan Kara <jack@...e.cz>,
	Christoph Hellwig <hch@....de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Al Viro <viro@...IV.linux.org.uk>, Tejun Heo <tj@...nel.org>,
	Pavel Machek <pavel@....cz>, <linux-kernel@...r.kernel.org>,
	<linux-fsdevel@...r.kernel.org>, <linux-pm@...r.kernel.org>
Subject: Re: [PATCH 0/3] PM, vfs: use filesystem freezing instead of kthread
 freezer

On Fri, 30 Oct 2015, Jiri Kosina wrote:

> This series is a followup to my proposal I brought up on Kernel Summit in 
> Seoul. Noone seemed to had any principal objections, so let's have wider 
> audience look into it.
> 
> In a nuthsell: freezing of kernel threads is horrible interface with 
> unclear semantics and guarantees, and I am surprised it ever worked 
> properly. Plus there are a lot of places that simply use it in a 
> completely wrong way (which is not suprising, given the lack of defined 
> semantics and requirements).
> 
> I've tested this over a series of suspend/resume cycles on several 
> machines with at least ext4, btrfs and xfs, and it survived the testing 
> without any harm.
> 
> Patch 1/3 	implements the actual change, and has a more detailed 
> 		explanation on "why?" and "how?" questions in the changelog

This patch talks about freezing in relation to hibernation.  What about 
other forms of suspend?

Also, it replaces kthread freezing with filesystem freezing.  What 
about kthreads performing I/O that doesn't go through a filesystem?  
You write:

> the only facility that is needed during suspend: "no persistent fs
> changes are allowed from now on"

I would say instead "no I/O is allowed from now on".  Maybe that's an 
overstatement, but I think it comes closer to the truth.

> Patch 2/3	nukes all (hopefully) the calls to freezer from kthreads 
> 		in Linus' tree (as of 858e904bd71)
> 
> Patch 3/3	introduces WARN_ON() if anyone is trying to make use of 
> 		this again
> 
> Open questions / discussion points:
> 
> - is the way I am traversing list of superblocks backwards enough to 
>   guarantee correct ordering? Especially: does this work as intended for 
>   FUSE?
> 
> - should freezable workqueues be dealt with the same way? I haven't even 
>   started to look into them in a serious way, but it seems like the 
>   drivers that are making use of them would actually like to use proper
>   PM callbacks instead

In the examples of freezable workqueues that I'm familiar with, what we 
really want is for the queue to stop running before the system goes any 
further into suspend.  This could be implemented with PM callbacks, but 
using the freezer instead seems a lot simpler.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/