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:	Fri, 28 May 2010 16:06:28 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Brian Swetland <swetland@...gle.com>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Igor Stoppa <igor.stoppa@...ia.com>, tytso@....edu,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	"Balbi Felipe (Nokia-D/Helsinki)" <felipe.balbi@...ia.com>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

> I think the suggestion that has the closet fit with what we're trying
> to accomplish is Ingo's (or perhaps Ingo's explanation of Alan's):
> http://lkml.org/lkml/2010/5/28/106 where it's implemented as a
> constraint of some sort.

I think we ended up in the same place on our own.

> Arve points out that qos constraint objects could work (but not if
> specifically tied to apps): http://lkml.org/lkml/2010/5/28/120 though
> he suggests that "latency" constraints don't represent this as well as
> "state" constraints.

With latency you have an "I don't give damn" latency in your model which
we could describe as infinite or "manyana" perhaps.

> Though if you look at it that way, then suspend_blockers become qos
> constraint objects, but their implementation and usage remain pretty
> much the same as we have now, which does not address Alan's concern
> regarding code turning up in drivers, etc.  I'm not sure how you can
> solve this problem (avoiding races around entering/exiting the suspend
> or suspend-like state) without having a means for drivers to prevent
> entry to that state.

I am much much less concerned about general expressions of constraint
appearing in drivers. One of my early mails gave a list of other
people/projects/problems that need them - from hard real time, to high
speed serial on low end embedded to virtualisation.

They fix a general problem in terms of a driver specific item. We end up
making changes around the tree but we make everyone happy not just
Android. Also we are isolating policy properly. The apps and drivers say
"I have these needs", the power manager figures out how to meet them.

Where it gets ugly is if you start trying to have drivers giving an app a
guarantee which the app then magically has to know to dispose of.

If you are prepared to exclude untrusted apps from perfectly reliable
event reporting (ie from finger to application action) that doesn't seem
to be a neccessity anyway.
 
> livelock/deadlock/priority-inversion style issues due to interaction
> between different processes in different groups.

Priority inversion with the cgroup case is like synchronization effects
with the suspend blockers - its a real ugly problem and one that is known
to be hard to fix if you let it happen so I agree there.

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

Powered by blists - more mailing lists