From: Suresh Siddha Date: Tue, 17 Mar 2009 00:04:53 +0000 (-0700) Subject: x86, x2apic: fix lock ordering during IRQ migration X-Git-Tag: v2.6.30-rc1~211^2~21^11~13 X-Git-Url: http://git.openpandora.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=4c5502b1c5744b2090414e1b80ca6388d5c46e06;p=pandora-kernel.git 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-diff-tree failed