Joe Korty <[email protected]> writes:
> IRQ_MOVE_PENDING must be cleared whenever it is bypassed.
>
> Otherwise, we risk an old, pending affinity change
> overtaking and erasing a more recent affinity change that
> had been directly applied (eg, IRQ_MOVE_PCNTXT mode).
When can this happen?
Eric
On Thu, Apr 30, 2009 at 12:49:39PM -0400, Eric W. Biederman wrote:
> Joe Korty <[email protected]> writes:
>
> > IRQ_MOVE_PENDING must be cleared whenever it is bypassed.
> >
> > Otherwise, we risk an old, pending affinity change
> > overtaking and erasing a more recent affinity change that
> > had been directly applied (eg, IRQ_MOVE_PCNTXT mode).
>
> When can this happen?
Probably doesn't happen. AFAIK, each IRQ is either fully MSI
or non-MSI. The MSI IRQs will always use IRQ_MOVE_PCNTXT and
the non-MSI's will never use IRQ_MOVE_PCNTXT. Thus no collision.
It could only happen if it was possible for a MSI and non-MSI
device to share an IRQ.
Joe
Joe Korty <[email protected]> writes:
> On Thu, Apr 30, 2009 at 12:49:39PM -0400, Eric W. Biederman wrote:
>> Joe Korty <[email protected]> writes:
>>
>> > IRQ_MOVE_PENDING must be cleared whenever it is bypassed.
>> >
>> > Otherwise, we risk an old, pending affinity change
>> > overtaking and erasing a more recent affinity change that
>> > had been directly applied (eg, IRQ_MOVE_PCNTXT mode).
>>
>> When can this happen?
>
> Probably doesn't happen. AFAIK, each IRQ is either fully MSI
> or non-MSI. The MSI IRQs will always use IRQ_MOVE_PCNTXT and
> the non-MSI's will never use IRQ_MOVE_PCNTXT. Thus no collision.
>
> It could only happen if it was possible for a MSI and non-MSI
> device to share an IRQ.
Ok. I thought you might have seen something.
It doesn't happen and it can't happen, making your patch wrong.
Eric