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:	Sun, 23 Oct 2011 18:18:04 -0700
From:	mark gross <markgross@...gnar.org>
To:	NeilBrown <neilb@...e.de>
Cc:	Alan Stern <stern@...land.harvard.edu>, 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)]

Sorry for going AWOL on this thread.  I had some biz travel and fires to
fight.

On Mon, Oct 17, 2011 at 08:37:17AM +1100, NeilBrown wrote:
> 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.

Timeout?  why can't we define a proper notification handshake for such
things?  Timeouts are never right IMO.

--mark



> Thanks,
> NeilBrown


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