linux-kernel - Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

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: <20100528152037.2568f2fb@lxorguk.ukuu.org.uk>
Date:	Fri, 28 May 2010 15:20:37 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Brian Swetland <swetland@...gle.com>
Cc:	Igor Stoppa <igor.stoppa@...ia.com>,
	ext Matthew Garrett <mjg59@...f.ucam.org>,
	"tytso@....edu" <tytso@....edu>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	"Balbi Felipe (Nokia-D/Helsinki)" <felipe.balbi@...ia.com>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

> > That's very good. But if it is done in a conceptually flawed way, some
> > better solution should be considered for upstream merge.
> 
> How is it flawed?  Serious question.

- It means changing drivers and quite a few apps
- It doesn't solve the problem of rogue apps if they end up owning locks
- It puts the deep knowledge of the platform in the applications
- It gives the apps control of the action taken not policy indication
- It doesn't resolve the problem of synchronization of take/releases
  stopping any suspend
- The kernel parts are not generically useful, merely effective for
  solving a specific problem right now - even things like VM migration
  to/from phones seems to break it
- It inverts the whole logic the kernel is following and trend it is
  following that suspend is simply a very deep idle (with implementations
  merged)

If it was a localised turd I wouldn't worry. There are plenty df deep
unmentionables hidden away enirely in platform specific code that deal
with everything from stoned hardware engineers to crazed software stack
implementations.

Here is a question back the other way perhaps

- If the existing kerne was almostl entirely read only, or you had to pay
  a large fee per line of code changed outside your own driver how would
  you implement the wakelock/suspend blocker API ?

Because if you take the path that 'we want wakelockers' that is
essentially the question you have to answer. How do you merge it so that
nobody outside of your driver and maybe a spot of arch code knows about
it. You are permitted a couple of sneaky substitions of core function
bits in headers.

Right now bits are going to leak out over the kernel which is the cause of
friction. At the point it's invisible to everyone else they cease to be
stakeholders so you don't have keep them happy. You've only got a couple
in your patches but its painfully obvious from Matthew and your comments
you'll end up needing a ton more and these will get everywhere as Android
grows hardware platforms and CPU support as phones become more featureful
and PC like. The moment a phone grows a USB base station with hub for
example the entire USB stack becomes burdened with them. Matthew has
already indicated networking needs them. Good luck with Dave Miller on
that.

I'm asking questions to look for generalised approaches, or even better
doing it without new kernel stuff in the first place, but it's not the
only way.

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