Messages in this thread | | | Date | Thu, 2 Dec 2004 23:01:06 -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: > > __handle_sysrq was modified to do a spin_lock_irqsave so we were > entering smp_send_stop with interrupts. So enable interrupts in > machine_shutdown(). > > Signed-off-by: Zwane Mwaikambo <zwane@holomorphy.com> > > Index: linux-2.6.10-rc2-mm4/arch/i386/kernel/reboot.c > =================================================================== > RCS file: /home/cvsroot/linux-2.6.10-rc2-mm4/arch/i386/kernel/reboot.c,v > retrieving revision 1.1.1.1 > diff -u -p -B -r1.1.1.1 reboot.c > --- linux-2.6.10-rc2-mm4/arch/i386/kernel/reboot.c 30 Nov 2004 18:52:19 -0000 1.1.1.1 > +++ linux-2.6.10-rc2-mm4/arch/i386/kernel/reboot.c 3 Dec 2004 04:28:28 -0000 > @@ -274,6 +274,8 @@ void machine_shutdown(void) > #ifdef CONFIG_SMP > int reboot_cpu_id; > > + local_irq_enable();
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? ;) - 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/
| |