From 4c5502b1c5744b2090414e1b80ca6388d5c46e06 Mon Sep 17 00:00:00 2001 From: Suresh Siddha Date: Mon, 16 Mar 2009 17:04:53 -0700 Subject: [PATCH] x86, x2apic: fix lock ordering during IRQ migration Impact: fix potential deadlock on x2apic fix "hard-safe -> hard-unsafe lock order detected" with irq_2_ir_lock On x2apic enabled system: [ INFO: hard-safe -> hard-unsafe lock order detected ] 2.6.27-03151-g4480f15b #1 ------------------------------------------------------ swapper/1 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: (irq_2_ir_lock){--..}, at: [] get_irte+0x2f/0x95 and this task is already holding: (&irq_desc_lock_class){+...}, at: [] setup_irq+0x67/0x281 which would create a new lock dependency: (&irq_desc_lock_class){+...} -> (irq_2_ir_lock){--..} but this new dependency connects a hard-irq-safe lock: (&irq_desc_lock_class){+...} ... which became hard-irq-safe at: [] 0xffffffffffffffff to a hard-irq-unsafe lock: (irq_2_ir_lock){--..} ... which became hard-irq-unsafe at: ... [] __lock_acquire+0x571/0x706 [] lock_acquire+0x55/0x71 [] _spin_lock+0x2c/0x38 [] alloc_irte+0x8a/0x14b [] setup_IO_APIC_irq+0x119/0x30e [] setup_IO_APIC+0x146/0x6e5 [] native_smp_prepare_cpus+0x24e/0x2e9 [] kernel_init+0x5a/0x176 [] child_rip+0xa/0x11 [] 0xffffffffffffffff Fix this theoretical lock order issue by using spin_lock_irqsave() instead of spin_lock() Signed-off-by: Suresh Siddha Signed-off-by: H. Peter Anvin --- Reading git-format-patch failed