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]

Date:	Fri, 28 May 2010 10:49:58 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>,
	<felipe.balbi@...ia.com>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Fri, 28 May 2010, Peter Zijlstra wrote:

> On Thu, 2010-05-27 at 20:59 -0400, Alan Stern wrote:
> > On Fri, 28 May 2010, Rafael J. Wysocki wrote:
> > 
> > > > And the forced-suspend design relies on the fact that processes remain 
> > > > frozen throughout.  If we leave some processes unfrozen and one of them 
> > > > somehow becomes runnable, that means we have to abort the forced 
> > > > suspend before the process is allowed to run.
> > > 
> > > We could avoid that if drivers could block tasks, but there are questions to
> > > answer.  First off, how a driver is supposed to know when to block the task
> > > using it and when to do its power management transparently for the task?
> > > Second, how to intercept and block all possible interfaces that user space
> > > can use to talk to drivers (how to intercept a task using mmapped device, for
> > > example)?
> > 
> > We talked about this a few years ago and decided it was not feasible.  
> > It would require substantial changes to every device driver.
> 
> But what if its the _right_ thing to do? We make changes to every device
> driver out there on a regular basis. Also, why won't an incremental
> process work? Add the interface with a fallback for drivers that haven't
> implemented it and implement it for those drivers its most urgent (like
> those in use on an Android phone).

There is no reasonable fallback.  In fact, I seriously doubt that
there's any way to carry this out at all, reasonable or not.  For
example, how do you handle the situation where a user task gets an
error because it accessed an mmapped address belonging to a device that
has been suspended?

> Not doing the right thing simply because its a lot of work seems like a
> fine way to let the kernel rot into an unmaintainable mess.

Firstly, it's not at all clear that this _is_ the right thing.

Secondly, when doing the right thing involves making invasive changes 
to half the .c files in the kernel, people might stop to think that it 
would add more bugs than it would solve problems.

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/