Re: 2.6.18-rc6-mm1: GPF loop on early boot

[Ingo Molnar]

* Andi Kleen <ak@xxxxxxx> wrote:

> > 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)
> 
> I disagree with that.  The nightmare is putting stuff that needs so 
> much infrastructure into the most basic operations.

ugh, "having a working current" is "so much infrastructure" ?? Lockdep 
uses a very low amount of infrastructure, considering its complexity: it 
has its own allocator, uses raw spinlocks, raw irq flags ops, it 
basically implements its own infrastructure for everything. Being able 
to access a per-task data area (current) is a quite fundamental thing 
for kernel code.

the i686 PDA patches introduce tons of early_current() uses. While i 
like the new PDA code, its bootstrap (like x86_64's PDA bootstrap) is 
too fragile in my opinion, and it will regularly hit instrumenting 
patches.

Perhaps the early setup code (if we really want to do it all in C) 
should be moved into 32-bit early boot userspace code (like 
compressed/misc.c) and it will thus not depend on any kernel 
infrastructure.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/