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 18:27:56 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Florian Mickler <florian@...kler.org>,
	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, Rafael J. Wysocki wrote:

> > 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.
> 
> You assume that these two steps will occur instantaneously one after the other,
> while there may be (and in fact there should be) a delay between them.

No, I'm not assuming that.

> I would make the power manager wait for certain time after reading
> /sys/power/wakeup_count and if no wakeup events are reported to it within
> that time, to write to /sys/power/wakeup_count.

Why?  That's just wasted time -- time during which the system could 
have been suspended.

I can understand the power manager might reason as follows: If this
wakeup event hasn't been handed over to a userspace program in the next
5 seconds, I'm going to suspend anyway on the theory that something is
wrong.  But why do that when you can get exact information?

> The length of the time to wait would be system-dependent in general, but I'd
> also allow the event consumers to influence it (like when an application knows
> it will process things for 10 minutes going forward, so it tells the power
> manager to wait for at least 10 minutes before attempting to suspend).

It tells the power manager to wait by activating a userspace suspend
blocker.  While a blocker is active, the power manager doesn't have to
poll /sys/power/wakeup_count or anything; it just waits for all the
suspend blockers to be deactivated.  And there's no guesswork involved;  
the power manager knows immediately when it's time to try suspending
again.

> > 	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.
> 
> Which I don't think is really necessary, because we'll need to use timeouts
> anyway, at least for events that have no user space consumers.

You wouldn't need to use timeouts for them either if the kernel had a 
way to indicate when it was finished processing events.

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