![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2005-03-22 14:08 [from the cache] ©2003-2008 | |||||||||||||