linux-kernel - Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

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: <20100517181252.GA14260@gandalf>
Date:	Mon, 17 May 2010 21:12:53 +0300
From:	Felipe Balbi <me@...ipebalbi.com>
To:	James Bottomley <James.Bottomley@...e.de>
Cc:	me@...ipebalbi.com, Kevin Hilman <khilman@...prootsystems.com>,
	Alan Stern <stern@...land.harvard.edu>,
	linux-omap@...r.kernel.org, Theodore Ts'o <tytso@....edu>,
	Geoff Smith <geoffx.smith@...el.com>,
	Brian Swetland <swetland@...gle.com>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Tejun Heo <tj@...nel.org>,
	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Liam Girdwood <lrg@...mlogic.co.uk>,
	Matthew Garrett <mjg@...hat.com>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

Hi,

On Mon, May 17, 2010 at 01:59:39PM -0400, James Bottomley wrote:
> Have you actually tried this?  On my N1 with CM5.0.6 just running
> powertop requires me to keep the USB system up (debugging cable) and
> paths into the usb console ... all of this produces significant wakeup
> distortion, mostly in the msm i2c subsystem.  But in all the noise it's
> hard to find rogue applications.

Well, I use serial console, but in the worst case scenario I would make
powertop save the output to a memory buffer a big one, and after
finished flush to some mmc or anything like that.

> The technical reason for wanting suspend blockers (as has been stated
> more times than I can be bothered to go back and count) is that no-one
> can currently produce a working model for race free kernel to user work
> handoff and, in the face of open app stores, rogue applications are a
> significant problem.  The fact that suspend blockers enables easy
> identification of power hogging apps is just a very useful side effect.

I still can't get over the fact that suspend_blockers are dealing with
userland problems in kernel space. If we can't really trust apps, I'm
sorry but companies like Google and Nokia (which I work for) will have
to setup better application acceptance on their stores. The fact that we
can get statistics of power usage from kernel space is actually really
good and could be easily automated on an AppStore environment. If it's
cause too many wakeups you report that to the developer of the app
before accepting. The same feature could be shipped on the SDK, so
developer has also early feedback about how good (or bad) his/her
application really is to the system.

IMO we should be celebrating good apps, not dealing in kernel space with
bad ones. And on top of all that, we would still need custom
applications with suspend_blockers support built into them.

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