linux-kernel - 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:	Mon, 21 Jun 2010 12:54:44 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Florian Mickler <florian@...kler.org>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Neil Brown <neilb@...e.de>, mark gross <640e9920@...il.com>
Subject: Re: [RFC][PATCH] PM: Avoid losing wakeup events during suspend

On Mon, 21 Jun 2010, Florian Mickler wrote:

> > > > What happens if an event arrives just before you read
> > > > /sys/power/wakeup_count, but the userspace consumer doesn't realize
> > > > there is a new unprocessed event until after the power manager checks
> > > > it?
> > 
> > > I think this is not the kernel's problem.  In this approach the kernel makes it
> > > possible for the user space to avoid the race.  Whether or not the user space
> > > will use this opportunity is a different matter.
> > 
> > It is _not_ possible for userspace to avoid this race.  Help from the 
> > kernel is needed.
> 
> It is possible if every (relevant) userspace program implements a
> callback for the powermanager to check if one of it's wakeup-sources
> got activated.
> 
> That way the powermanager would read /sys/power/wakeup_count, then do
> the roundtrip to all it's registered users and only then suspend. 

After further thought, there's still a race:

	A wakeup event arrives.

	The kernel increments /sys/power/wakeup_count and starts
	processing the event.

	The power-manager process reads /sys/power/wakeup_count.

	The power-manager process polls the relevant programs and
	they all say no events are pending.

	The power-manager process successfully writes 
	/sys/power/wakeup_count.

	The power-manager process initiates a suspend.

	...  Hours later ...

	The system wakes up.

	The kernel finishes its internal processing of the event and
	sends a notification to a user program.

The problem here is that the power-manager process can't tell when the
kernel has finished processing an event.  This is true both for events
that need to propagate to userspace and for events that are handled
entirely by the kernel.

This is a reflection of the two distinct pieces of information that we 
need to keep track of:

	A wakeup event has arrived, so it's no longer safe to suspend.

	Wakeup events are no longer pending, so it's once again
	safe to suspend.

The wakeup_count interface tracks the first, but in this scheme nothing 
tracks the second.

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/