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]

Message-ID: <20100805015815.GN2927@count0.beaverton.ibm.com>
Date:	Wed, 4 Aug 2010 18:58:15 -0700
From:	Matt Helsley <matthltc@...ibm.com>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	"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, swetland@...gle.com,
	peterz@...radead.org, tglx@...utronix.de, alan@...rguk.ukuu.org.uk
Subject: Re: Attempted summary of suspend-blockers LKML thread

On Wed, Aug 04, 2010 at 05:35:09PM +0100, Matthew Garrett wrote:
> On Wed, Aug 04, 2010 at 09:32:16AM -0700, Paul E. McKenney wrote:
> 
> > If this doesn't work for the Android folks for whatever reason, another
> > approach would be to do the freeze in user code, which could track
> > whether any user-level resources (pthread mutexes, SysV semas, whatever)
> > where held, and do the freeze on a thread-by-thread basis within each
> > "victim" application as the threads reach safe points.
> 
> The main problem I see with the cgroups solution is that it doesn't seem 
> to do anything to handle avoiding loss of wakeup events.

cgroups alone don't but there is a solution which doesn't require routing
all event data through a single server -- use SIGIO.

Suppose we've got two cgroups of tasks -- those in the initial freezer
cgroup and those in a freezer cgroup meant for power-naive apps. Let's
call the second cgroup the naive cgroup.

One task -- let's call it the "waker" -- is in the initial cgroup is normaly
asleep waiting for SIGIO. Note it's not an "app" -- it's been trusted/blessed
to be a non-power-naive task. It will be signaled via SIGIO by the
applications which want to be unfrozen when an event comes in.

When the power-naive app in the naive cgroup opens a file descriptor it's
going through the Android interpretter to make the syscall. The interpretter
can do fcntl() on the fd to cause SIGIO to be delivered to the waker task.
When the waker gets SIGIO it unfreezes the naive cgroup and thus wakes the
power-naive app. When the power-naive app wakes it will
poll/return-from-poll/read/return-from-read and thus retrieve the event.

Then it's just a matter of choosing when to freeze the naive cgroup. That
requires a userspace implementation of the suspend blockers API plus
opportunistic suspend but does not require any other kernel pieces. Then you
can use sigprocmask to prevent the freeze/wake-event race. You would
probably even merge the waker with the daemon which implements
opportunistic suspend.

Cheers,
    -Matt Helsley
--
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/