Messages in this thread | | | Date | Tue, 17 Jan 2006 23:37:34 -0800 | From | Andrew Morton <> | Subject | Re: 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/
| |