linux-kernel - Re: Changes to PM layer break userspace

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: <20061220042648.GA19814@srcf.ucam.org>
Date:	Wed, 20 Dec 2006 04:26:48 +0000
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	David Brownell <david-b@...bell.net>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, gregkh@...e.de
Subject: Re: Changes to PM layer break userspace

On Tue, Dec 19, 2006 at 07:59:42PM -0800, David Brownell wrote:
> On Tuesday 19 December 2006 4:25 pm, Matthew Garrett wrote:
> > 1) feature-removal-schedule.txt says that it'll be removed in July 2007. 
> > This isn't July 2007.
> 
> Which is why the functionality is still there.

Merely broken in the majority of cases...

> > 2) The functionality was disabled in 2.6.19. The addition to 
> > feature-removal-schedule.txt was in, uh, 2.6.19.
> 
> Please respond to the technical explanation I provided, and stop
> referring to the functionality ** which is still there and works **
> as being disabled.

The breakage is that devices that are happy to suspend with enabled 
interrupts can no longer be suspended from userspace. Refusing to 
suspend a single device on the basis that some other driver on the bus 
may, potentially, at some point require some suspend code to be run with 
disabled interrupts is not a sensible choice. Especially since I can't 
actually find a single driver in the kernel tree that currently uses 
this functionality.

> I can't help it if that schedule.txt patch took until 2.6.19 to get
> upstream; ISTR it was available before 2.6.18 shipped.  Maybe patches
> to that file should be accelerated, even into the stable series.

That would still not have provided anywhere near enough warning. 

> One of the missing steps in Linus' formulation there is that not all
> interfaces are equivalent in terms of support guarantee.  Bugs are
> interfaces, for example, and sometimes folk wrongly depend on them
> when they persist for a long time (like, cough, this one).

The existence of the power/state interface wasn't a bug - it was a 
deliberate decision to add it. It's the only reason the 
dpm_runtime_suspend() interface exists. It's perfectly reasonable to 
refer to it as a flawed interface, or perhaps even a buggy one. But in 
itself, it's clearly not a bug. And it's perfectly reasonable for 
userland to depend on interfaces that are deliberately exposed by the 
kernel.

> In contrast, the /sys/devices/.../power/state API has never had many
> users beyond developers trying to test their drivers (without taking
> the whole system into a low power state, which probably didn't work
> in any case), and has *always* been problematic.  And the change you
> object to doesn't "break" anything fundamental, either.  Everything
> still works.

It's used on every Ubuntu and Suse system, and the change means that 
certain functionality no longer works - it's now impossible to prevent 
my wireless hardware from drawing power when I'm not using it, for 
example. If the WE power operations were deliberately disabled, then 
that would also be a bug.

-- 
Matthew Garrett | mjg59@...f.ucam.org
-
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/