Hi,
On 22/03/18 14:06, Julien Grall wrote:
> Hi Andre,
>
> On 03/22/2018 11:56 AM, Andre Przywara wrote:
>> + /* The locking order forces us to drop and re-take the locks
>> here. */
>> + if ( irq->hw )
>> + {
>> + spin_unlock(&irq->irq_lock);
>> +
>> + desc = irq_to_desc(irq->hwintid);
>> + spin_lock(&desc->lock);
>> + spin_lock(&irq->irq_lock);
>> +
>> + /* This h/w IRQ should still be assigned to the virtual
>> IRQ. */
>> + ASSERT(irq->hw && desc->irq == irq->hwintid);
>> +
>> + have_desc_lock = true;
>> + }
>
> I am a bit concerned of this dance in fold_lr_state(). This looks
> awfully complex but I don't have better solution here.
I agree.
> I will have a think during the night.
>
> However, this is not going to solve the race condition I mentioned
> between clearing _IRQ_INPROGRESS here and setting _IRQ_INPROGRESS in
> do_IRQ. This is because you don't know the order they are going to be
> executed.
>
> I wanted to make sure you didn't intend to solve that one. Am I correct?
This is right, this is orthogonal and not addressed by this patch. I
have a hunch we need to solve this in irq.c instead.
Cheers,
Andre.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
