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]

Message-Id: <200803171327.16695.lenb@kernel.org>
Date:	Mon, 17 Mar 2008 13:27:15 -0400
From:	Len Brown <lenb@...nel.org>
To:	Éric Piel <Eric.Piel@...mplin-utc.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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

I agree with Linus' decision to revert/disable this feature.
I think it is appropriate to muck with this in -mm, but not in -rc6
Kudos to Christoph, who recommended we revert it back at -rc2.

> > What's the problem with just loading a new DSDT later? Potentially as in 
> > *much* later: including when user-space is all up-and-running? 

I don't think re-loading the DSDT at run-time would be practical.

First, booting with the OEM DSDT may nullify the benefit
of overriding the OEM DSDT -- the damage may have already been done.

Secondly, unwinding everything that depends on the DSDT is on the
order of kexec or suspend/resume.  We're talking about all the stuff
that PNP does at boot time, plus device discovery and driver binding.

The feature on the table here is an initrd DSDT override.
We already have the ability to statically compile a DSDT
override into the kernel image.  That capability is sufficient
for kernel developers.

The initrd version of the DSDT override is really for one scenario.
Somebody who has a BIOS that even Windows can't deal with -- so
no amount of "Windows bug compatbility" will help Linux with it.
They must be capable eough to generate or acquire a modified DSDT.
They must be unwilling/unable to re-build their kenrel from scratch
each time they update it.  Eg. following debian unstable updates etc.

I think that customer deserves support, particularly because they get
bragging rights that Linux works better on a box build for Windows
than Windows does:-)
However, I don't think there are enough customers like this to
justify a huge effort that would add risk to Linux.

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