[PATCH] x86-64: Use irq_domain in ioapic_retrigger_irq

Thanks to YH Lu for spotting this.  It appears I missed this function when I
refactored allocate_irq_vector and introduced irq_domain, with the result that
all retriggered irqs would go to cpu 0 even if we were not prepared to receive
them there.

While reviewing YH's patch I also noticed that this function was missing
locking, and since I am now reading two values from two diffrent arrays that
looks like a race we might be able to hit in the real world.

Cc: Yinghai Lu <yinghai.lu@amd.com>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Andi Kleen <ak@suse.de>

diff --git a/arch/x86_64/kernel/io_apic.c b/arch/x86_64/kernel/io_apic.c
index b848f48085100075cc275070a5dbc233139de366..8a9a357875b72d66a4ce0ddae14a5d347c973045 100644 (file)
--- a/arch/x86_64/kernel/io_apic.c
+++ b/arch/x86_64/kernel/io_apic.c
@@ -1255,12 +1255,15 @@ static int ioapic_retrigger_irq(unsigned int irq)
 {
        cpumask_t mask;
        unsigned vector;
+       unsigned long flags;
 
+       spin_lock_irqsave(&vector_lock, flags);
        vector = irq_vector[irq];
        cpus_clear(mask);
-       cpu_set(vector >> 8, mask);
+       cpu_set(first_cpu(irq_domain[irq]), mask);
 
-       send_IPI_mask(mask, vector & 0xff);
+       send_IPI_mask(mask, vector);
+       spin_unlock_irqrestore(&vector_lock, flags);
 
        return 1;
 }