[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121016125021.GA22935@sgi.com>
Date: Tue, 16 Oct 2012 07:50:21 -0500
From: Dimitri Sivanich <sivanich@....com>
To: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>
Cc: x86@...nel.org, Suresh Siddha <suresh.b.siddha@...el.com>,
Joerg Roedel <joerg.roedel@....com>,
Yinghai Lu <yinghai@...nel.org>,
Alexander Gordeev <agordeev@...hat.com>,
linux-kernel@...r.kernel.org
Subject: [PATCH] x86: check for valid irq_cfg pointer in
smp_irq_move_cleanup_interrupt
Posting this patch to fix an issue concerning sparse irq's that I raised
a while back. There was discussion about adding refcounting to sparse
irqs (to fix other potential race conditions), but that does not appear to
have been addressed yet. This covers the only issue of this type that I've
encountered in this area.
A NULL pointer dereference can occur in smp_irq_move_cleanup_interrupt() if
we haven't yet setup the irq_cfg pointer in the irq_desc.irq_data.chip_data.
In create_irq_nr() there is a window where we have set vector_irq in
__assign_irq_vector(), but not yet called irq_set_chip_data() to set the
irq_cfg pointer.
Should an IRQ_MOVE_CLEANUP_VECTOR hit the cpu in question during this time,
smp_irq_move_cleanup_interrupt() will attempt to process the aforementioned
irq, but panic when accessing irq_cfg.
Only continue processing the irq if irq_cfg is non-NULL.
Signed-off-by: Dimitri Sivanich <sivanich@....com>
---
arch/x86/kernel/apic/io_apic.c | 3 +++
1 file changed, 3 insertions(+)
Index: linux/arch/x86/kernel/apic/io_apic.c
===================================================================
--- linux.orig/arch/x86/kernel/apic/io_apic.c
+++ linux/arch/x86/kernel/apic/io_apic.c
@@ -2257,6 +2257,9 @@ asmlinkage void smp_irq_move_cleanup_int
continue;
cfg = irq_cfg(irq);
+ if (!cfg)
+ continue;
+
raw_spin_lock(&desc->lock);
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists