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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 15 Mar 2008 20:42:52 +0100
From:	Éric Piel <Eric.Piel@...mplin-utc.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Tilman Schmidt <tilman@...p.cc>, Dave Hansen <haveblue@...ibm.com>,
	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

15/03/08 20:21, Linus Torvalds wrote/a écrit:
> 
> 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.
Hi,
It's a pity, I had just nearly finished a new approach. Instead of
relying on populate_rootfs() and the filesystem infrastructure, the new
approach directly finds the file in the initramfs. With
unpack_to_rootfs(), it turned out to be rather straightforward. Attached
 is a half-tested version of the patch (it boots and works but I haven't
compiled without the option yet). Just in case you would like to change
your mind ;-)


> 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!
Indeed, this form of DSDT override would be the best. However, I have no
idea what is necessary to implement it. Len, does this approach sound
feasible? Where should I start looking at?

Eric


View attachment "0001-DSDT-in-initramfs-directly-access-the-initramfs.patch" of type "text/plain" (7355 bytes)