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.1005271730180.3239-100000@iolanthe.rowland.org>
Date:	Thu, 27 May 2010 17:38:03 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
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, Alan Cox wrote:

> > That's the point -- suspend does not evaluate the system state 
> > correctly because it doesn't have the necessary information.  Suspend 
> 
> The power management layer knows if the machine is idle, it has insight
> into when the next wakeups will occur.

But not the kind of insight we need.  See below.

> > blockers are a way of providing it that information.  They don't paper 
> > over the problem; they solve it.
> 
> I'm still unconvinced (see Thomas examples as a starter) and even if they
> did, the cure would be far worse than the disease.

Perhaps.

> The hardware world also shows how you handle suspend/resume event races
> cleanly and in turn how we can handle right from user to hardware.
> 
> If you are dealing with a well behaved UI app then its event loop will
> just do
> 
> 	if (message == UI_OFF) {
> 		stop_background_stuff();
> 		event_mask &= stuff;
> 		send_reply(NIGHT_NIGHT);
> 		continue;
> 		/* Back to poll() */
> 	}
> 
> 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?

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

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

> You have one person who needs to
> track the sequence - that's however is the guy sending UI_ON/UI_OFF
> information and making the screen light up.
> 
> If you are dealing with a badly behaved app then you can't win because it
> may not have the magic 'suspend blockers' or will do it wrong.

Agreed.  Badly behaved apps must not be allowed to block suspends.  As 
far as I'm concerned, we can ignore them.

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/