linux-kernel - Re: [markgross@...ngar.org: [RFC] wake up notifications and suspend blocking (aka more wakelock stuff)]

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:	Tue, 25 Oct 2011 00:05:48 -0700
From:	Brian Swetland <swetland@...gle.com>
To:	NeilBrown <neilb@...e.de>
Cc:	markgross@...gnar.org, Alan Stern <stern@...land.harvard.edu>,
	linux-kernel@...r.kernel.org, John Stultz <john.stultz@...aro.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, arve@...roid.com,
	amit.kucheria@...aro.org, farrowg@...ibm.com,
	"Dmitry Fink (Palm GBU)" <Dmitry.Fink@...m.com>,
	linux-pm@...ts.linux-foundation.org, khilman@...com,
	Magnus Damm <damm@...nsource.se>, mjg@...hat.com,
	peterz@...radead.org
Subject: Re: [markgross@...ngar.org: [RFC] wake up notifications and suspend
 blocking (aka more wakelock stuff)]

On Sun, Oct 23, 2011 at 6:50 PM, NeilBrown <neilb@...e.de> wrote:
> But saying "Timeouts are never right" cannot work - unless you mean it in a
> much more restricted sense than I think you mean it.
>
> (I can agree that it is *best* if timeouts never fire - if direct action
> causes the wakeup-source to deactivate long before the timeout.  I agree that
> is the best case and probably should be the common case, but I cannot see how
> it can be the only case).

This was our conclusion when originally building the Android wakelock
APIs.  Timeouts are undesirable, and whenever we can ensure there's a
clear handoff of "ownership" of a wakeup event, so it's fully
accounted for, that's the preferred way to go.  But reality gives us
situations where we can't know with a certainty what woke us up (or we
won't know until some time has passed -- USB resume, etc) and in those
situations, timeouts are the best solution we have.  Over time we've
always hoped to have fewer and fewer timeouts, but I'm not certain
that we'll ever reach zero, for non-trivial systems.

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/