linux-kernel - Re: acpi dsts loading and populate

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:	Sun, 10 Feb 2008 12:58:09 +0100
From:	Eric Piel <eric.piel@...mplin-utc.net>
To:	Christoph Hellwig <hch@....de>
Cc:	dsdt@...gusch.at, len.brown@...el.com,
	linux-kernel@...r.kernel.org, Linus Torvalds <torvalds@...l.org>,
	trenn@...e.de
Subject: Re: acpi dsts loading and populate_rootfs

(adding some CC's)
Christoph Hellwig wrote:
> On Sun, Feb 10, 2008 at 08:12:26AM +0100, Christoph Hellwig wrote:
>> Folks, moving this call around hidden behing in completely unreviewed
>> acpi junk is not acceptable.
>>
>> Either populate_rootfs _is_ safe to be called earlier and then we should
>> do it always or it's not.  Either way such a change should be posted
>> separately and reviewd on lkml.
Hi,

I agree with you, the order of the initialization should not be changed 
by some config options. Either it works, or it doesn't! So the question 
now is : "is fine to move populate_rootfs() earlier?"

Some data points:
* It used to be called earlier. It was moved to be called later about a 
year ago by Linus (8d610dd52dd1da696e199e4b4545f33a2a5de5c6) with this log:
>     Make sure we populate the initroot filesystem late enough
>     
>     We should not initialize rootfs before all the core initializers have
>     run.  So do it as a separate stage just before starting the regular
>     driver initializers.
So there must be some good reasons to keep it late enough...

* This patch is used in SuSE, and it seems noone has ever had a problem 
with the initramfs early init.

I guess the problem that Linus solved by moving populate_rootfs() 
happens only rarely or on only few configurations. Linus, do you 
remember what kind of problem it was? How can I reproduce it?

One different solution that I implemented [1] was to have an 
"early_populate_rootfs()" before the acpi_early_init(), leaving 
populate_rootfs() at the normal place. If the early version fails, it's 
ok: we can't override the DSDT, but the later version will work as usual 
anyway. This solution also seems to work quite often (it's used in 
Ubuntu, Mandriva and PCLinuxOS)

Would that seem an acceptable solution? Or what other way exists?


>> Len, can you please revert "ACPI: basic initramfs DSDT override support"
>> aka commit 71fc47a9adf8ee89e5c96a47222915c5485ac437 until we've sorted
>> this out properly?  Thanks.
> 
> And while we're at it the file reading thing in there is utter crap
> aswell.  You really should be using the firmware loader which works
> perfectly fine if you initramfs is set up for it.  So please folks,
> back to the drawing board, do it properly and send it out to lkml
> for review please.
Christoph, if you have seen this part of the code, you have probably 
also read the big fat warning explaining why this cannot be done by 
firmware loader (ie: userspace cannot be run at this early time, 
corresponding to acpi_early_init()). However, you probably know the 
kernel ten times better than me. Could you explain what I misunderstood 
when writing this warning, and give me some hints about how to use the 
firmware loader in this case?

See you,
Eric


[1] : 
http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.8.4-2.6.21.patch

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