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]

Message-ID: <47DC66A8.1020905@tremplin-utc.net>
Date:	Sun, 16 Mar 2008 01:15:36 +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 21:19, Linus Torvalds wrote/a écrit:
> 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? 
> 
:
> So what's the reason for pushing for this insanely-early workaround in the 
> first place, instead of letting user-space do something like
> 
> 	cat my-dsdt-image > /proc/sys/acpi/DSDT
> 
> or whatever at runtime?
Yeah, or probably more something like this nowadays ;-)
	cat my-dsdt-image > /sys/firmware/acpi/tables/DSDT

As I said in my previous email, I'm already convinced that late-override
of ACPI table approach would be very interesting to investigate.
However, this cannot be taken lightly. A _lot_ of places in the kernel
depend on the ACPI and nothing has ever been done in the direction of
dynamic modification of the APCI tables. The implementation is likely to
be much bigger than the current 100 lines of patch.

That said, it should be possible to draw some assumptions without
restraining much the functionality. Such as:
 * every object present in the original table is still present is the
new table
 * they keep the same name

Len, do you think it would be feasible? How do you think the
implementation could be done?

Eric

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