[Xen-changelog] [xen-unstable] x86/IRQ: fix valid-old-vector checks in __assign_irq_vector()

[Xen patchbot-unstable <patchbot@xxxxxxx>]

# HG changeset patch
# User Jan Beulich <jbeulich@xxxxxxxx>
# Date 1348817014 -7200
# Node ID 41f523f1b5e5af9cf8e85160f2412456da83050f
# Parent  6a581212909478bba0c7b4dfc6c370270dee825c
x86/IRQ: fix valid-old-vector checks in __assign_irq_vector()

There are two greater-than-zero checks for the old vector retrieved,
which don't work when a negative value got stashed into the respective
arch_irq_desc field. The effect of this was that for interrupts that
are intended to get their affinity adjusted the first time before the
first interrupt occurs, the affinity change would fail, because the
original vector assignment would have caused the move_in_progress flag
to get set (which causes subsequent re-assignments to fail until it
gets cleared, which only happens from the ->ack() actor, i.e. when an
interrupt actually occurred).

This addresses a problem introduced in c/s 23816:7f357e1ef60a (by
changing IRQ_VECTOR_UNASSIGNED from 0 to -1).

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Acked-by: Keir Fraser <keir@xxxxxxx>
---


diff -r 6a5812129094 -r 41f523f1b5e5 xen/arch/x86/irq.c
--- a/xen/arch/x86/irq.c        Fri Sep 28 09:22:14 2012 +0200
+++ b/xen/arch/x86/irq.c        Fri Sep 28 09:23:34 2012 +0200
@@ -430,8 +430,7 @@ static int __assign_irq_vector(
      * 0x80, because int 0x80 is hm, kind of importantish. ;)
      */
     static int current_vector = FIRST_DYNAMIC_VECTOR, current_offset = 0;
-    unsigned int old_vector;
-    int cpu, err;
+    int cpu, err, old_vector;
     cpumask_t tmp_mask;
     vmask_t *irq_used_vectors = NULL;
 

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog