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: <20100527230806.4deb6de3@lxorguk.ukuu.org.uk>
Date:	Thu, 27 May 2010 23:08:06 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	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>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Thu, 27 May 2010 17:38:03 -0400 (EDT)
Alan Stern <stern@...land.harvard.edu> wrote:

> > and power management does the rest. If an event wakes up the process
> > before we get to suspend in kernel we will wake it back up.
> 
> Okay, and the kernel never suspends.  We _are_ talking about a kind of
> forced suspend, right?

No ? We are talking about just letting power management solve the whole
problem for us.

> >  If the event
> > gets in after pm decides to idle via suspend then it'll bounce through
> > the kernel back to a kernel resume,
> 
> No, it won't.  That's the problem suspend blockers were meant to solve.  
> The event winds up sitting in a kernel queue, the PM core doesn't know
> about it (that's what I meant above -- the PM core doesn't know as much
> as you seem to think it does), and the suspend takes place regardless.

No - because we are not forcing the suspend. The app must go idle. If you
force the suspend of running processes then yes the entire thing goes
castors up - which is why it's a bad idea to do so.

> > or potentially through a full
> > hardware/software suspend/resume bounce.
> 
> It would be okay if that happened.  But once the event gets into the
> kernel and the hardware IRQ source has turned off, there's nothing to
> cause the resume.

Read the discussion about how the race is avoided at the hardware level.
That race is I think not there and furthermore most drivers get it right
already.

There are several cases

1.	IRQ during app layer (ie policy in user space) asking
		applications to go passive

	- The event occurs, we undo the app layer policy, easy
	  (or app wakes process and we let it fall through)

2.	IRQ after the app layer quiesces its clients

	- The task wakes, the app layer won't see it - the app layer
	  allows suspend as an idle mode. Not a problem - the app is
	  running the cpu policy manager will see this and not suspend
	  until the app has been asleep for a bit. The app may well of
	  course tell the UI layer 'hey I want you back on' and it take
	  you back to the full on case.

3.	IRQ after kernel suspend begins

	- The driver will refuse the suspend, we don't suspend, we unwind
	  the resume so far, the app wakes, we propogate stuff back up to
	  user space whose policy manager unwinds its position

4.	IRQ after driver has done its final checks

	- Wake up lines are set
	- We suspend
	- We immediately get resumed
	- We follow the full resume path

This is I believe robust (and has been implemented on some non x86
boxes). It depends on not forcing running tasks into suspend. That is the
key.

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