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

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


* Andi Kleen <[email protected]> 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 

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 

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at
Please read the FAQ at

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux