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]
Message-ID: <Pine.LNX.4.44L0.1006241037080.1654-100000@iolanthe.rowland.org>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ