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:	Mon, 17 Oct 2011 08:37:17 +1100
From:	NeilBrown <neilb@...e.de>
To:	Alan Stern <stern@...land.harvard.edu>
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 21:49:44 -0400 (EDT) Alan Stern
<stern@...land.harvard.edu> wrote:

> All right, let's make things a little more complicated.

Let's call it "realistic".   It is good to have some realism to make sure our
abstract discussions actually mean something.

> 
> Here's what actually happens when a USB keyboard generates a wakeup 
> request.  The system wakes up, of course, but there's no particular 
> indication of the cause.  In particular, the usbhid driver has no way 
> to know directly that the keyboard was the reason for the wakeup.
> 
> In addition, usbhid can't poll keyboards to see if they have an event
> to report.  (In theory it could -- the HID protocol allows for this --
> but many keyboards don't support that part of the protocol properly.)  
> It has to wait until the keyboard gets around to reporting the event, 
> which can take 10 ms or more.
> 
> Taken together, this means usbhid must activate a wakeup_source every
> time it wakes up.  If a keyboard event report is received reasonably
> quickly then good, it can deactivate the wakeup_source at the right
> time.  But if not, all the driver can do is time out the wakeup_source
> after some delay.  I don't see any way to avoid it.

I have to agree with you there.
This is similar to Rafael's example of a Wake-on-LAN packet arriving.  At
that point there is nothing you can do except wait a little while expecting
more information.

You could see this as a case where the wake-up event isn't even visible to
the kernel, so there is obviously no way to make it visible to user-space.

Or you could see it as a wake-up event that is expected to be delivered over
a long period of time (many msecs).  The kernel gathers the wake-up event,
makes it visible to user-space (once it actually arrives), and then releases
the wakeup_source.

So it is a good example and highlights the difficulty of defining exactly
what a wake-up event it, and of what it means to be "visible".

I think it still fits in your rephrasing of my question which - if I rephrase
it as a requirement - is roughly,

  A wakeup-event that needs to be handled by user-space must be visible to
  user-space before the driver deactivates the wakeup_source.

A requirement which, in this case, means the driver needs to hold  the
wakeup_source for an extended time using a timeout, just as you say.

Thanks,
NeilBrown

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)