linux-kernel - Re: Attempted summary of suspend-blockers LKML thread

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]

Date:	Thu, 5 Aug 2010 08:15:35 -0700
From:	Brian Swetland <swetland@...gle.com>
To:	david@...g.hm
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	pavel@....cz, florian@...kler.org, rjw@...k.pl,
	stern@...land.harvard.edu, peterz@...radead.org,
	tglx@...utronix.de, alan@...rguk.ukuu.org.uk
Subject: Re: Attempted summary of suspend-blockers LKML thread

On Thu, Aug 5, 2010 at 7:34 AM,  <david@...g.hm> wrote:
>
> for example, if you want to abort the suspend because there is network
> activity, you can check the packet count of your network interface, decide
> to go to sleep, setup the network interface to raise a 'wake me up'
> interrupt (because you have decided in a userspace policy that you want
> this), and then check to see if the packet count has changed. If it has,
> abort the suspend, if not continue the suspend and once you are suspended if
> the 'wake me up' interrupt is set you will wake back up.
>
> there are probably cleaner/better ways of doing this than the simple logic
> that I'm listing, but why wouldn't the simple logic provide the correct
> result?

If your network interrupt happens before the network driver's
suspend() hook is called this works -- the check in the suspend hook
observes the change and returns an abort status.

If your network interrupt happens after the suspend() hook is called
this does not work -- the event comes after your opportunity to abort
suspend has happened, your interrupt handler processed it, set the
flag, but the system proceeds to suspend anyway, missing the event.

The wakelock/suspendblock mechanism avoids races like the above.

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