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: <47DAE55C.3080506@tremplin-utc.net>
Date:	Fri, 14 Mar 2008 21:51:40 +0100
From:	Eric Piel <eric.piel@...mplin-utc.net>
To:	Dave Hansen <haveblue@...ibm.com>
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

Dave Hansen wrote:
> For those of you new to this thread, here's the initial report:
> 
> 	http://marc.info/?t=120536629300001&r=1&w=2
> 
> I'm pretty sure the root cause of this bug is this commit:
> 
> 	ACPI: basic initramfs DSDT override support
> 	71fc47a9adf8ee89e5c96a47222915c5485ac437
> 
> Which did this hunk:
>         
>         @@ -648,6 +654,7 @@ asmlinkage void __init start_kernel(void)
>          
>                 check_bugs();
>          
>         +       populate_rootfs(); /* For DSDT override from initramfs
>         */
>                 acpi_early_init(); /* before LAPIC and SMP init */
>          
>                 /* Do the rest non-__init'ed, we're now alive */
>         	rest_init();
>         ...
> 
> Well, the fs initcalls aren't actually done until during rest_init(),
> including initializing my mnt_writer[] spinlocks.  I guess I could
> statically initialize them, but that's not the root of the problem, it's
> just the canary in the coal mine.
> 
> I think the populate_rootfs() call is completely bogus and certainly
> can't be done before the initcalls.  But, I don't immediately have any
> better suggestions for you.  Can you delay the ACPI init until after the
> fs initcalls are made?
Hi,

I have made a patch to fix problems with regards to early userspace 
calls (http://lkml.org/lkml/2008/2/23/306) but I don't think it will 
solve this bug. So far I had not heard of problems with filesystem 
initialization.

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?

See you,
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/