linux-kernel - Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

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:	Sat, 15 Mar 2008 12:21:53 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Tilman Schmidt <tilman@...p.cc>
cc:	Dave Hansen <haveblue@...ibm.com>,
	Eric Piel <eric.piel@...mplin-utc.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Thomas Renninger <trenn@...e.de>,
	Len Brown <len.brown@...el.com>,
	Christoph Hellwig <hch@...radead.org>,
	Markus Gaugusch <dsdt@...gusch.at>, linux-acpi@...r.kernel.org,
	Al Viro <viro@...IV.linux.org.uk>,
	Arjan van de Ven <arjanv@...hat.com>
Subject: Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

On Sat, 15 Mar 2008, Tilman Schmidt wrote:
> 
> Sorry to say, it doesn't. That is, it does shut up the warning I
> reported, but there's a new one appearing now instead, three lines
> later.

I've reverted the whole thing. Or rather, since there were various small 
fixup commits over time, and a simple revert doesn't really work, I ended 
up just removing the option and the code that was conditional on it - that 
way, if we really want to fight this out some time (after 2.6.25 is out) 
or some vendor wants to use a known-broken option anyway, there's a simple 
and fairly clean commit to revert the revert.

It's commit 9a9e0d685553af76cb6ae2af93cca4913e7fcd47, see 

	http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9a9e0d685553af76cb6ae2af93cca4913e7fcd47

for details if you aren't a git person.

But quite frankly I don't think that we even want to re-introduce this in 
that form. If we really want to have a dynamic custom DSDT, I think we 
should do the whole DSDT replacement *much* later by ACPI (like just 
before driver loading or something like that).

If the BIOS-provided DSDT is _so_ broken that we cannot even get core 
stuff like the CPU's going, I think it has more serious issues than any 
custom DSDT will ever fix, but letting ACPI actually switch DSDT's at 
run-time (instead of just replacing it when looking for it very very early 
in the boot sequence) in order to work around some device issues sounds 
reasonably sane.

So how about aiming to make that DSDT-replacement something you can do 
from any kernel module, _after_ the original DSDT has already been parsed? 
And then the whole "load it from initrd" turns into a regular thing that 
we can do pretty early, but that we don't have to do quite _this_ early!

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