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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.1110151435080.15129-100000@netrider.rowland.org>
Date:	Sat, 15 Oct 2011 14:45:37 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	NeilBrown <neilb@...e.de>
cc:	markgross@...gnar.org, <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 Sat, 15 Oct 2011, NeilBrown wrote:

> On Thu, 13 Oct 2011 11:16:23 -0400 (EDT) Alan Stern
> <stern@...land.harvard.edu> wrote:
> 
> > On Thu, 13 Oct 2011, NeilBrown wrote:
> > 
> > > Nope, but I'm keen for you to convince me.  Identify a wakeup event that
> > > cannot be made visible to poll (or to user-space by some other
> > > mechanism) before the wakeup_source needs to be deactivated.  Or if I've
> > > misunderstood what sort of notification is problematic, help me understand.
> > 
> > Here's an example (just for kicks, not completely relevant to your
> > discussion): A USB keyboard key release.  Unlike key presses, key
> > releases need not generate input events.  If no processes are
> > monitoring the raw keyboard event queue then the release is not visible
> > to userspace at all, hence not visible before the wakeup_source needs
> > to be deactivated.
> > 
> > Alan Stern
> 
> As you say, not completely relevant.
> 
> If a tree falls in a forest with no one to here, does it make a sound?
> 
> similarly if an event happens that no-one is looking for, is it visible?
> It doesn't really matter.

That's a different question, but I'll answer it anyway: Yes, it does
matter.  If the kernel is unable to _know_ that nobody is looking for
an event, it has to _assume_ that somebody is.  Then what should happen 
if it turns out that nobody really is looking for it?

> So at most this is a case of "is not made visible" rather than "cannot be
> made visible".

In this case it's the same thing.  How can a key release be made 
visible?

> The key-release just needs to clear the "key is pressed" state so that
> auto-repeat stops and if it was a modifier, the modification is discarded.
> That is all trivially done in some kernel driver while the wakeup_source is
> active.

In other words, if the event is discarded from within the kernel then 
the wakeup_source can be deactivated at that time.  That's fine -- but 
it indicates that your original request above was phrased wrongly.  You 
should have asked for an example of a wakeup_source which the kernel 
must not deactivate without a userspace handshake, but which cannot be 
made visible by poll or some other similar mechanism.

Alan Stern

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