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]

Date:	Thu, 27 May 2010 00:00:04 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Brian Swetland <swetland@...gle.com>
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

> desired.  The device node interface came about after discussions last
> year and concerns that userspace could create an unbounded number of
> suspend blockers.

Surely you only need one block per task (or better yet one expression of
latency per task). If not can you explain why a setup which has a per
task expression of latency needs (and a 'hard limit' set which you can't
then bump back down except as root) isn't enough ?

I'd really like this lot to also fix the hard real time and power
management problem we have today and to try an fix the "suspend is
special and different" mentality in the kernel, which is getting less and
less true on a variety of chips.

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

Great - but the world is not Android and even if they can't access it
directly but get passed a handle they can play.

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

By drivers I agree but in the driver case the cost is minimal because
there should not be many and it is bounded clearly. Again I really think
'suspend blocking' is the wrong expression.

A driver needs to express

'Don't go below this latency'

and

'Don't go below this state'

This is more generic and helps our power management do the right thing on
all boxes. For example a serial port can meaningfully say 'I want X
latency worst case' based upon the fact the fifo is 64 bytes and the user
space just asked for 115,200 baud.

The don't go below for states out of which the device must wake but
cannot. Eg if your device is being told by user space to set wake on lan
and can only wake on lan from a higher state than 'off' it needs to say
so.

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