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:	Fri, 14 Mar 2008 14:35:51 -0700
From:	Dave Hansen <haveblue@...ibm.com>
To:	Eric Piel <eric.piel@...mplin-utc.net>
Cc:	Tilman Schmidt <tilman@...p.cc>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Thomas Renninger <trenn@...e.de>,
	Len Brown <len.brown@...el.com>,
	Linus Torvalds <torvalds@...l.org>,
	Christoph Hellwig <hch@...radead.org>,
	Markus Gaugusch <dsdt@...gusch.at>, linux-acpi@...r.kernel.org
Subject: Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

On Fri, 2008-03-14 at 21:51 +0100, Eric Piel wrote:
> I'm not sure it would be possible to delay acpi_early_init() until after 
> the fs initcalls. Maybe Len knows. How about trying the opposite: what 
> is the barely minimum to initialize so that the rootfs can be populated 
> and read? Would it be possible to have a kind of 
> early_mnt_writer_initialize() that would do that?

I *can* probably do it earlier, maybe even statically, but I think
you're missing the point a bit here.  We've just been super lucky so far
that populate_rootfs() doesn't depend on any other initcalls (or at
least BUG_ON() because of them).  There may be some more buglets hiding
around.

It'd be a shame to have to have "super_early_fs_initcall()" logic for
every part of the VFS or any other initcall for that matter that you
might need.  How do we tell all future VFS hackers that they have to do
this so that the next guy doesn't break it?  I certainly missed it. :)

We could separate out the initcalls and just have the fs ones run before
the rest do.  But, I'm not sure what interactions *THAT* might have.
There are arch-specific initcalls, and I have no idea if the fs init
code depends on *those*.  That's a lot of code to check.

It is nailed when you the patch says:

+       /*
+        * Never do this at home, only the user-space is allowed to open a file.
+        * The clean way would be to use the firmware loader. But this code must be run
+        * before there is any userspace available. So we need a static/init firmware
+        * infrastructure, which doesn't exist yet...
+        */

I think requiring FS access this early in the boot processes is just
broken.  It seems like the author of the patch knew a better way and
tried to get away with a hack.  I think it backfired. :)

-- Dave

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