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]

Date:	Thu, 27 May 2010 19:12:39 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Arve Hjønnevåg <arve@...roid.com>,
	Florian Mickler <florian@...kler.org>,
	Vitaly Wool <vitalywool@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Paul@...p1.linux-foundation.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, May 27, 2010 at 07:02:04PM +0100, Alan Cox wrote:
> > This is still racy. Going back to this:
> > 
> > int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0);
> > char foo;
> > struct sockaddr addr;
> > connect (input, &addr, sizeof(addr))
> > while (1) {
> >        if (read(input, &foo, 1) > 0) {
> >                (do something)
> >        } else {
> > 		* SUSPEND OCCURS HERE *
> 
> Fine but then the packet will arrive and we will wake back up process the
> packet and wake the task. See suspend is just like a deep sleep. If we
> went to sleep there and the packet arrival doesn't rewake the box the
> driver was buggy.

Yes, there's no problem so far. The question is how you guarantee that 
the application has had the opportunity to handle the packet.

> > reaches the end of its timeslice. At this point the application has not 
> > had an opportunity to indicate in any way whether or not the packet has 
> > altered its constraints in any way. What stops us from immediately 
> > suspending again?
> 
> If my app level constraint before the packet is 'don't suspend' then my
> constraint on receipt is 'don't suspend' so I won't suspend. If my
> constraint is then lowered and I suspend I will suspend *after* the
> lowering.

If the app level constraint before the packet was "don't suspend", we 
wouldn't have suspended. Here's a description of the desired behaviour 
of the application as you requested:

The application is a network monitoring app that renders server state 
via animated bouncing cows. The desired behaviour is that the 
application will cease to be scheduled if the session becomes idle 
(where idle is defined as the system having received no user input for 
30 seconds) but that push notifications from the server still be 
received in order to allow the application to present the user with 
critical alerts.

Under Android:

User puts down phone. 30 seconds later the screen turns off and releases 
the last user-level suspend block. The phone enters suspend and the 
application is suspended. A network packet is received, causing the 
network driver to take a suspend block. The application finishes the 
frame it was drawing, takes its own suspend block and reads the network 
packet. In doing so the network driver releases its suspend block, but 
since userspace is holding one the phone stays awake. The application 
then handles the event as necessary, releases its suspend block and the 
phone goes to sleep again.

I don't see how this behaviour can be emulated in your model.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/