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.1005271253240.3239-100000@iolanthe.rowland.org>
Date:	Thu, 27 May 2010 13:00:38 -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>,
	<Paul@...p1.linux-foundation.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 whole notion of treating suspend to RAM any different than a plain
> idle C-State is wrong. It's not different at all. You just use a
> different mechanism which has longer takedown and wakeup latencies and
> requires to shut down stuff and setup extra wakeup sources.

This is where you are wrong.  Maybe not wrong in principle, but wrong 
in practice -- the kernel's present suspend-to-RAM (or just "suspend") 
implementation is _very_ different from C-states (or just "idle").

The primary difference is that the kernel can be forced into suspend
even when the system isn't idle.  In particular, it may be in the
middle of processing a potential wakeup event -- and the current design
gives the PM core no way to know if that is so.  This is a weakness
that in-kernel suspend blockers fix.

With C-states this can't happen.  If the CPU goes into a deeper C-state 
then ipso facto it isn't busy processing anything, much less a wakeup 
event.

Now maybe this difference is a bad thing, and the whole PM 
suspend/hibernate infrastructure should be rewritten.  But the fact, 
remains, that's how it works now.  And it can't be changed easily or 
quickly.

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/