Messages in this thread | | | Date | Thu, 2 Dec 2004 23:36:11 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH][BUG] Badness in smp_call_function at arch/i386/kernel/smp.c:552 |
| |
Zwane Mwaikambo <zwane@holomorphy.com> wrote: > > > Well, sort-of. > > > > If __handle_sysrq was really a normal IRQ handler then the correct thing to > > do here is to replace spin_lock_irqsave() with spin_lock(). But > > __handle_sysrq() can also be called via /proc/sysrq-trigger and via the > > handlers of multiple interrupt sources. So we're stuck with using > > spin_lock_irqsave(). > > > > However enabling interrupts as you've done menas that theoretically we > > could deadlock on sysrq_key_table_lock if another sysrq happens at the > > wrong time. > > > > Which deadlock opportunity would you prefer? ;) > > Agreed, there is actually a higher chance of the smp_call_function > deadlock occuring since the __handle_sysrq one relies on another sysrq > event occuring via a different IRQ line interrupt handler, so > we would have to do sysrq via serial and then sysrq via keyboard to cause > the deadlock. Perhaps just make it a spin_trylock?
Well yeah, but it's so much fuss for such a silly problem.
How about a local_irq_enable() in sysrq_handle_reboot()? - 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/
| |