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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ