linux-kernel - Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

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: <AANLkTikqYwcJfCSJgBlXKyyDJFAVJmrZmyt38KOby97j@mail.gmail.com>
Date:	Wed, 26 May 2010 15:18:35 -0700
From:	Brian Swetland <swetland@...gle.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Peter Zijlstra <peterz@...radead.org>,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	linux-kernel@...r.kernel.org, Randy Dunlap <rdunlap@...otime.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ryusuke Konishi <konishi.ryusuke@....ntt.co.jp>,
	Jim Collar <jim.collar@...are.net>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Avi Kivity <avi@...hat.com>, Len Brown <len.brown@...el.com>,
	Pavel Machek <pavel@....cz>, Magnus Damm <damm@...l.co.jp>,
	Nigel Cunningham <nigel@...onice.net>,
	linux-doc@...r.kernel.org
Subject: Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend 
	blockers from user-space

On Wed, May 26, 2010 at 3:14 PM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>> This whole thing is related to the statistics part, which Arve says is
>> essential to him.  He wants to collect statistics for each suspend blocker
>> activated and deactivated so that he can tell who's causing problems by
>> blocking suspend too often.  The name also is a part of this.
>
> If he wants to collect stats about misbehaving code then presumably he
> needs reliable stats. Arbitary user set names are not reliable and
> judging by app vendor behaviour in the proprietary space with other such
> examples they will actively name their blockers in a manner specifically
> intended to hide the cause so as to 'reduce support costs'.
>
> Its a waste of memory (especially if I create a million of them with a
> long name for fun).

You are limited to one per open fd of the device, and a max name size
which could be further shrunk to something pretty small (32?) if
desired.  The device node interface came about after discussions last
year and concerns that userspace could create an unbounded number of
suspend blockers.

> It's all an economic system, proprietary app vendors are in it to make
> money, some will therefore game the system and the rest will be forced to
> follow to keep their playing field fair.

Untrusted (non-system) code can't directly access the device node from
userspace in the Android world -- so directly created suspend blockers
from userspace are only created by a couple system processes (3-4
typically).  Applications are sandboxed by UID and there is (much
more) per-application accounting in the userspace application manager
process (other resource consumption such as sensors, CPU, etc is
tracked here as well).

For suspend blockers created by drivers and by trusted userspace
processes, having a meaningful name significantly helps statistics
gathering.

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/