| 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
| ||
|
Date: Fri, 28 May 2010 15:05:37 +0100 From: Matthew Garrett <mjg59@...f.ucam.org> To: Alan Cox <alan@...rguk.ukuu.org.uk> Cc: Arve Hjønnevåg <arve@...roid.com>, Alan Stern <stern@...land.harvard.edu>, Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra <peterz@...radead.org>, LKML <linux-kernel@...r.kernel.org>, Florian Mickler <florian@...kler.org>, felipe.balbi@...ia.com, Linux OMAP Mailing List <linux-omap@...r.kernel.org>, Linux PM <linux-pm@...ts.linux-foundation.org> Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) On Fri, May 28, 2010 at 02:55:26PM +0100, Alan Cox wrote: > The following cannot occur on my laptop for simple idling > > Alarm > Suspend > > because the Alarm resets the suspend timer when it is delivered. Userspace is about to write to /sys/power/state when it gets scheduled. Alarm delivery occurs at that instant. Kernel has no idea that it's about to go to sleep, so the driver handles things appropriately and clears the hardware state. Userspace gets scheduled, writes and the system suspends. The problem is that having userspace decidie to initiate a suspend and then actually initiate a suspend isn't an atomic operation. -- Matthew Garrett | mjg59@...f.ucam.org -- 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