linux-kernel - Re: [linux-pm] [PATCH] PM: Make it possible to avoid wakeup events from being lost

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] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.1006262254060.28065-100000@netrider.rowland.org>
Date:	Sat, 26 Jun 2010 23:06:59 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	David Brownell <david-b@...bell.net>
cc:	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, mark gross <640e9920@...il.com>,
	Florian Mickler <florian@...kler.org>,
	Neil Brown <neilb@...e.de>, <linux-pci@...r.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: [linux-pm] [PATCH] PM: Make it possible to avoid wakeup events
 from being lost

On Sat, 26 Jun 2010, David Brownell wrote:

> > > basically, I think the notion of counting wakeup
> > > events seems dubious on common hardware, ...
> > I disagree. 
> > 
> > The "counting" isn't meant as a way of keeping track of the absolute
> > number of these events.  It's more like a technique  for seeing how many
> > remain outstanding at any time.
> 
> But if you can't count them with any
> reliability, you can't know *that* either... so
> there must be a a problem with that model.

Why do you say we can't count them with any reliability?

Or, let's put it another way: You'll grant that we can count _some_ set
of events.  Given that, you'll probably also grant that we can keep
track of their number reliably enough to know when the count has
dropped to 0.  Then this becomes a question of how closely does the set
of events we can count match up with the set of "wakeup" events?

In fact, it doesn't have to match up perfectly.  There may be a few
wakeup events where we don't really care if one of them occurs while
the system is going to sleep and the sleep isn't delayed or aborted.  
(Although by definition this is never _supposed_ to happen, there may
be cases where we just don't care.)  The other possibility is
relatively harmless too: an event that wouldn't wake up a sleeping
system nevertheless can delay or abort a suspend-in-progress.

So overall I don't see a problem with this.  Do you have any especially
pernicious failure modes in mind?

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/