linux-kernel - Re: 2.6.18-rc6-mm1: GPF loop on early 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: <20060910115722.GA15356@elte.hu>
Date:	Sun, 10 Sep 2006 13:57:23 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Andi Kleen <ak@...e.de>
Cc:	Laurent Riffard <laurent.riffard@...e.fr>,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...l.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Jeremy Fitzhardinge <jeremy@...source.com>
Subject: Re: 2.6.18-rc6-mm1: GPF loop on early boot

* Andi Kleen <ak@...e.de> wrote:

> > This kernel won't boot here: it starts a GPFs loop on
> > early boot. I attached a screenshot of the first GPF
> > (pause_on_oops=120 helped).
> 
> It's lockdep's fault. This patch should fix it:

Well, it's also x86_64's fault: why does it call into a generic C 
function (x86_64_start_kernel()) without having a full CPU state up and 
running? i686 doesnt do it, never did.

We had frequent breakages due to this property of the x86_64 arch code 
(many more than this single incident with lockdep), tracing and all 
sorts of other instrumentation (including earlier versions of lockdep) 
was hit by it again and again.

Basically, non-atomic setup of basic architecture state _is_ going to be 
a nightmare, lockdep or not, especially if it uses common infrastructure 
like 'current', spin_lock() or even something as simple as C functions. 
(for example the stack-footprint tracer was once hit by this weakness of 
the x86_64 code)

> Hackish patch to fix lockdep with PDA current

hm, this is ugly beyond words. Do you have a config i could try which 
exhibits this problem? I'm sure there is a better solution.

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