Re: mutex vs. local irqs (Was: 2.6.18 -mm merge plans)

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Thu, 2006-06-08 at 13:17 +0200, Roman Zippel wrote:
> Hi,
> 
> On Thu, 8 Jun 2006, Benjamin Herrenschmidt wrote:
> 
> > > a better solution would be to install boot-time IRQ vectors that just do
> > > nothing but return. They dont mask, they dont ACK nor EOI - they just
> > > return. The only thing that could break this is a screaming interrupt,
> > > and even that one probably just slows things down a tiny bit until we
> > > get so far in the init sequence to set up the PIC.
> > 
> > Changing vectors on the fly is hard on some platforms.... We could
> > change our toplevel ppc_md.get_irq() on powerpc, but we still to do
> > something about decrementer interrupts.
> 
> On ppc it should not be that difficult to even modify the exception entry 
> code. Instead of calling do_IRQ use do_early_IRQ and only install the real 
> handler later.

Yes, it's possible, but will add overhead to the common  IRQ path just
to handle an early boot special case.

> > A screaming level interrupt will lockup the machine at least on some
> > platforms.
> 
> I guess that's even deadly on most platforms.

Yup.

> > The problem with all those approaches is that they require changes to
> > all archs interrupt handling to make the situation safe vs. mutexes...
> 
> Only those archs that want to delay interrupt initialization and they at 
> least have to provide minimal support to survive enabled interrupts.
> init_IRQ() stays the same for all other archs and we add another hook to 
> allow the delayed initializtion.

I'm taking a broader point of view here. More than just interrupt init,
it's in general having basic kernel services such as memory allocator,
which shouldn't need any special hardware initialization outside of the
mmu, be setup before we start banging hardware.

> > I still don't think where is the suckage in just not hard-enabling in
> > the mutex debug code...
> 
> If you want to have full services, then irqs are part of it. :)

No. THere is, imho, a very clear difference between services that do
rely on hw devices, ioremap, and such major infrastructure as page
tables, and services like slab which essentially, can be initialized
with the CPU itself being ready and nothing else.

Cheers,
Ben.