linux-kernel - Re: [PATCH 0/6] [RFC] Proposal for optimistic suspend idea.

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: <alpine.LFD.2.02.1109280953000.2711@ionos>
Date:	Wed, 28 Sep 2011 10:18:08 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	John Stultz <john.stultz@...aro.org>
cc:	Peter Zijlstra <peterz@...radead.org>,
	lkml <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, arve@...roid.com,
	markgross@...gnar.org, Alan Stern <stern@...land.harvard.edu>,
	amit.kucheria@...aro.org, farrowg@...ibm.com,
	"Dmitry Fink (Palm GBU)" <Dmitry.Fink@...m.com>,
	linux-pm@...ts.linux-foundation.org, khilman@...com,
	Magnus Damm <damm@...nsource.se>, mjg@...hat.com
Subject: Re: [PATCH 0/6] [RFC] Proposal for optimistic suspend idea.

On Tue, 27 Sep 2011, John Stultz wrote:
> On Wed, 2011-09-28 at 02:09 +0200, Thomas Gleixner wrote:
> > We have proper mechanisms in place to handle such stuff, but they need
> > proper overall design and definitely a bit more brain usage than just
> > yelling "wakelock".
> 
> And it would be great if some of that brain usage was spent to review
> and critique what I'm actually proposing, rather then just yelling
> "wakelock". :P

Working on it :)

> I apologize for being probably too verbose in my mails, but I did
> originally admit that the firmware update issue is a simpler problem and
> doesn't necessarily need the same solution as the races around my
> nightly backups. But I do think that some thought should be put into the
> different use cases that seem to desire similar things, so that an
> appropriate design can be created, instead of a collection of short-term
> hacks.

Yes, we want use cases, which can actually justify something like the
proposed.

Firmware update is _not_ one of them because it needs a proper design
to be completely failsafe and just preventing the box to suspend is
not helping that goal at all. You have to deal with broken network
connections, resets, power outage and more to make it failsafe. And
dealing with all of that covers the unintended suspend already. It
simply does not matter whether it happens or not.

And that's why I'm ranting about such arguments, as they will just
guide people into the delusion of solving hard problems like safe
firmware updates with the wrong mechanisms.

The whole wakelock discussion has been full of delusions from the very
beginning and we really need to eliminate the lunatic arguments so we
can look at the real remaining ones (if any), which might justify
them.

> More brain usage, and proper design. At least with that, I think we
> agree. :)

Right, and proper design does not exclude user space. It very much
starts there.

Thanks,

	tglx
--
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/