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: <alpine.LNX.2.00.1510302204280.17538@pobox.suse.cz>
Date:	Fri, 30 Oct 2015 22:17:54 +0100 (CET)
From:	Jiri Kosina <jikos@...nel.org>
To:	Alan Stern <stern@...land.harvard.edu>
cc:	Pavel Machek <pavel@....cz>,
	"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>,
	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, Alan Stern wrote:

> > > > 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.
> > 
> > But that's what PM callbacks are for.
> 
> Why are PM callbacks any more suitable than the freezer?  

Once the PM callback triggers, you know that you are really actually 
undergoing suspend and have to do whatever is necessary.

OTOH, try_to_freeze() is a kind of "are we there yet?" polling, and the 
whole state needs to be prepared pro-actively for suspend already when you 
call it, each and every time, even if you are not going through suspend at 
all.

That's sub-optimal, and very easy to get wrong over gradual code changes.

> The most natural implementation would be for the callback routine to set 
> a flag; at various strategic points the kthread would check the flag and 
> if it was set, call a routine that sits around and waits for the suspend 
> to be over.  

Could you name at least some existing kthreads that would actually *need* 
such complex handling, instead of just waiting in schedule() until 
suspend-resume cycle is over, given that PM callbacks do all the necessary 
cleanup (putting HW to sleep, cancelling timers, etc) anyway?

PM callback can always explicitly do kthread_stop() on a particular 
kthread if really necessary.

> Also, you never replied to my question about suspend vs. hibernation.

The main point of freezer is to reach quiescent state wrt. filesystems 
(metadata in memory need to be absolutely in sync with what's on disk). 
That's no different between hibernation and s2ram, is it?

BTW, a quite some of this has been already "pre-discussed" in 
Documentation/power/freezing-of-tasks.txt (which has BTW been written 
before we've had the possibility to freeze filesystems, and this fact is 
even point there out).

Thanks,

-- 
Jiri Kosina
SUSE Labs

--
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/