lkml.org 
[lkml]   [2006]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.15-mm4 failure on power5
Nathan Lynch <ntl@pobox.com> wrote:
>
> Andrew Morton wrote:
> > Ingo Molnar <mingo@elte.hu> wrote:
> > > - so buggy early bootup code which relies on interrupts being
> > > off might be surprised by it.
> >
> > I don't think it's necessarily buggy that bootup code needs interrupts
> > disabled. It _is_ buggy that bootup code which needs interrupts disabled
> > is calling lock_cpu_hotplug().
>
> I guess I don't understand -- why is it wrong for code that runs only
> in early early bootup, when there is only one process context, to use
> common code to e.g. register a hotplug cpu notifier?

OK, it's not wrong I guess - we're running code which requires
local_irq_disable() and that code is calling functions which do
local_irq_enable() but we know that those functions won't do that because
there cannot be any lock contention.

So it works, and will continue to work, but it's all rather unpleasant, IMO.

> Should the
> powerpc numa code be made to wait to register its notifier until
> initcall time or something?

I think the powerpc code is busted, really - it shouldn't be keeling over
like that if someone enables local interrupts. That being said, it's a
good way of detecting accidental interrupt-enablings.

> Yes, which would be why this code never triggered a warning when
> cpucontrol was a semaphore.

Yup. Perhaps a sane fix which preserves the unpleasant semantics is to do
irqsave in the mutex debug code.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-01-18 08:40    [W:0.084 / U:1.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site