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