linux-kernel - Re: [update] Re: [RFC][PATCH] PM: Avoid losing wakeup events during suspend

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:	Thu, 24 Jun 2010 10:45:09 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Andy Lutomirski <luto@....edu>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>, mark gross <640e9920@...il.com>,
	Neil Brown <neilb@...e.de>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	<Arve@...p1.linux-foundation.org>,
	Florian Mickler <florian@...kler.org>,
	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>
Subject: Re: [update] Re: [RFC][PATCH] PM: Avoid losing wakeup events during
 suspend

On Thu, 24 Jun 2010, Andy Lutomirski wrote:

> How does userspace handle this without races?  (I don't see an example 
> in a driver that talks to userspace in your code...)
> 
> For example, if I push a button on my keyboard, the driver calls 
> pm_wakeup_begin().  Then userspace reads the key from the evdev device 
> and tells the userspace suspend manager not to go to sleep.
> 
> But there's a race: the keyboard driver (or input subsystem) could call 
> pm_wakeup_end() before the userspace program has a chance to tell the 
> suspend manager not to sleep.

The assumption is that the user program will poll the evdev device.  
When the poll indicates data is available, the program will tell the 
userspace power manager not to go to sleep before reading the data.  
This avoids the race.

> One possibility would be for poll to report that events are pending 
> without calling pm_wakeup_end(), giving userspace a chance to prevent 
> itself from suspending before actually reading the event.

Exactly.  The critical section doesn't end until the events have been 
read.  Polling alone doesn't affect the critical section.

> (Also, should "echo mem >/sys/power/state" be different from "echo 
> mem_respect_suspend_blockers >/sys/power/state?"  If I physically press 
> the suspend key on my laptop, I want it to go to sleep even though I'm 
> still holding the Fn key that was part of the suspend hotkey.)

With Rafael's scheme, the difference is not in the write to
/sys/power/state but rather in the write to /sys/power/wakeup_count.  
If the power manager program doesn't write to /sys/power/wakeup_count
first then /sys/power/state takes effect immediately, just as it does
now.

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/