Re: [Xen-devel] [PATCH] x86/IRQ: fix valid-old-vector checks in __assign_irq_vector()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.09.12 at 16:57, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:

> On 27/09/12 15:50, Jan Beulich wrote:
>> 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>
>> ---
>> I have to admit that I don't understand why the value got changed in
>> the first place: 0 is as invalid a value as -1 for a vector to be used
>> for delivering hardware interrupts.
> 
> http://lists.xen.org/archives/html/xen-devel/2011-09/msg00193.html 
> 
> It was a suggestion for consistency with using -1 elsewhere in the irq
> code to mean unassigned.

Not really - there George suggested to use IRQ_VECTOR_UNASSIGNED,
but not to make that resolve to -1. My claim is that this manifest
constant could easily resolve to zero instead.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel