[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.10.0807282340590.14925@apollo.tec.linutronix.de>
Date: Mon, 28 Jul 2008 23:51:45 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Andi Kleen <andi@...stfloor.org>
cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
Venkatesch Pallipadi <venkatesh.pallipadi@...el.com>,
Len Brown <lenb@...nel.org>
Subject: Re: [PATCH] ACPI/CPUIDLE: prevent setting pm_idle to NULL
On Mon, 28 Jul 2008, Andi Kleen wrote:
> > The problem here is that the acpi/cpuidle code can be in a state where
> > the _save/old variables _ARE_ NULL because they had not been
> > initialized with the original pm_idle before the module is removed or
> > the cst state changes. So all we have to do is to prevent pm_idle to
> > be set to NULL.
>
> It still seems wrong to me to fall back to the cpuidle idle function
> instead of the earlier idle function just because cpuidle was loaded
> in a weird way.
WTF are you talking about ?
pm_idle_save is initialized with pm_idle (the original idle function
selected by the arch code).
When CST changes or the acpi/cpuidle modules are removed we need to
restore the original pm_idle function from pm_idle_save.
When pm_idle_save was not initialized, which can happen, then we wrote
NULL to pm_idle, which is obviously wrong. We simply want to avoid
that we write NULL into pm_idle.
That's all what the patch does. Nothing else.
This problem was hidden by the magic
if (!pm_idle)
pm_idle = default_idle;
in the arch/x86 code which was removed when I refactored the pm_idle
initialization code.
Just get it. That "if (!pm_idle)" check in the arch code was just
papering over the fact that the acpi code set pm_idle to NULL under
certain conditions.
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/
Powered by blists - more mailing lists