linux-kernel - Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

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.1005271744130.3239-100000@iolanthe.rowland.org>
Date:	Thu, 27 May 2010 17:49:51 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Thomas Gleixner <tglx@...utronix.de>
cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>,
	<felipe.balbi@...ia.com>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Thu, 27 May 2010, Thomas Gleixner wrote:

> > The two of you are talking at cross purposes.  Thomas is referring to 
> > idle-based suspend and Matthew is talking about forced suspend.
> 
> Yes, and forced suspend to disk is the same as force suspend to disk,
> which has both nothing to do with sensible resource management.

If I understand correctly, you are saying that all the untrusted 
applications should run with QoS(NONE).  Then they could do whatever 
they wanted without causing any interference.

And with idle-based power management (rather than forced suspend), 
there would be no issue with wakeup events getting unduly delayed.

Unless one of those events was meant for an untrusted application.  Is 
that the source of the difficulty?

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/