linux-kernel - Re: [PATCH][RFC] Kill off legacy power management stuff.

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: <200704181723.16241.lenb@kernel.org>
Date:	Wed, 18 Apr 2007 17:23:15 -0400
From:	Len Brown <lenb@...nel.org>
To:	"Robert P. J. Day" <rpjday@...dspring.com>, davej@...emonkey.org.uk
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH][RFC] Kill off legacy power management stuff.

On Wednesday 18 April 2007 16:23, Robert P. J. Day wrote:
> On Wed, 18 Apr 2007, Len Brown wrote:

> > Here is how it should work. CONFIG_ACPI and CONFIG_APM should both
> > available in a kernel build. However, at boot time, of ACPI is
> > active, then APM should be disabled.
> >
> > The pm_active flag used to handle this, but that method was BROKEN
> > when the CONFIG_PM_LEGACY #define was added.  Today, there are
> > systems (such as the Thinkpad T30) that will not boot if
> > CONFIG_PM_LEGACY is not defined.  The reason nobody is complaining
> > is because the distros are currently defining CONFIG_PM_LEGACY.
> > But when you nuke that option and everything under it, this bug will
> > be exposed and some systems will stop booting.
> 
> ok, i get it now and -- correct me if i'm wrong -- all my legacy PM
> removal patch was doing was exposing a design boo-boo in which
> APM/ACPI contention was being handled by a macro in a subsystem even
> older than either of them, right?

yeah, it didn't start out that way, the bug was added when the
CONFIG_PM_LEGACY #define was added.

> so all that needs to be done is add 
> back in a contention solution of some kind that doesn't rely on that
> ancient system, yes?

Yes, it is a matter of making the variable not go away when
the #define goes away.

> as for that thinkpad t30 situation, well, that's just borked, and
> should be fixed.

yes, the actual failure is that APM mode on the T30 hangs -- and that is
independent of the issue at hand.  However, there could be other
failures on other machines when both APM and ACPI think they are active.

> rday
> 
> p.s.  at the risk of repeating myself repetitively, do we now agree
> that what i was trying to remove *was* adequately ancient?  although
> it's clear that it has to be done slightly more carefully than was
> done in my initial patch.

yes, I think so.

> p.p.s.  patch improvements that will let me avoid doing any of that
> myself always welcome. :-)

well, I'm sorry that I've known about the APM issue for a long time
and done nothing about it.  I did ping davej when he broke it,
but his to-do list is probably even longer than mine.

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