Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dave Hansen wrote:
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.
Actually, each time I look at init/main.c I feel like we are super lucky that Linux boots ;-)


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. :)
Well, my point was that actually populate_rootfs() does _very_ little with regard to FS manipulation, acpi_find_dsdt_initrd() even less. The task of checking that everything needed is available beforehand is certainly not the same magnitude as the one of the Danaides as you seemed to implied ;-)

The fact is, this patch has been tested a lot, because it's been used by several distributions for a long time. I expect that the only potential problems are corner cases that are possible to work around.


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.
Yes, we agree on this. That would be crazy :-)


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. :)
I'm actually the author of this comment... The static/init firmware infrastructure that I mentioned was more just about a way to hide the fs access in a special part of the kernel, not avoiding it. We used to have a different way but it was even uglier: append the DSDT after the initramfs, and then access it _directly_. This implies teaching populate_rootfs() to not panic when seeing DSDTs and loosing the benefit of the compression.

That said, I'm really not against any complete different approach. All that is needed is being able to read a file early at boot (the DSDT) without having to recompile the kernel each time the file is modified. For instance someone had once mentioned modifying the in-kernel DSDT by unlinking and relinking the bzimage. If one can show me how to do that I'd be happy to implement it...

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux