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

[Xen patchbot-4.2-testing <patchbot@xxxxxxx>]

# HG changeset patch
# User Jan Beulich <jbeulich@xxxxxxxx>
# Date 1349338516 -7200
# Node ID 648c99c230ff3fe75052973251a37ba9c68c6f84
# Parent  051661b76ade63e9963b987e6917f6bc0a42f9c1
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>
xen-unstable changeset: 25962:41f523f1b5e5
xen-unstable date: Fri Sep 28 07:23:34 UTC 2012
---


diff -r 051661b76ade -r 648c99c230ff xen/arch/x86/irq.c
--- a/xen/arch/x86/irq.c        Thu Oct 04 10:14:44 2012 +0200
+++ b/xen/arch/x86/irq.c        Thu Oct 04 10:15:16 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