Re: [PATCH][BUG] Badness in smp_call_function at arch/i386/kernel/smp.c:552

[Andrew Morton <akpm@osdl.org>]

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? ;)