Re: [Xen-devel] [PATCH v3 1/2] IOMMU/spinlock: Fix a bug found in AMD IOMMU initialization

[Meng Xu <xumengpanda@xxxxxxxxx>]

>
>> In fact, the deadlock arises because IRQs interrupt asynchronously what the
>> CPU is doing, and that can happen when the CPU has taken the lock already. 
>> But
>> if the 'asynchronous' part goes away, we really don't care whether a lock is 
>> take
>> at time t1 with IRQ enabled, and at time t2 with IRQ disabled, don't you 
>> think?
>>
>
> Yes.
> Consistency may be helpful to avoid some easy-to-avoid lock errors.
> Moreover, without my fix, I think it would not lead dead lock, as the 
> pcidevs_lock is not being taken
> In IRQ context. Right?

I think without your fix, the deadlock may still happen due to the
rendezvous condition.
           CPU A                                |    CPU B
     | CPU C
Step 1| spin_lock                           |
Step 2|                                           | spin_lock_irq           |
Step 3|                                            | wait for A to unlock |
Step 4|
              | send rendezvous IPI to A and B
Step 5| receive IPI                             | wait for A to unlock |
Step 6| wait for B to handle the IPI    | wait for A to unlock |
Step 7| spin_unlock


Deadlock occurs at Step 6, IMO.

Unless we can prove that rendezvous won't happen while
spin_lock_irqsave is taken, we have the deadlock hazard.

Actually, I'm not quite sure when the rendezvous condition may happen
in  this situation. So probably, in reality, we don't have the
rendezvous condition.

>
>
> For deadlock, I think the key problems are:
>   - A lock can be acquired from IRQ context
>   -The interrupt is delivered to the _same_CPU_ that already holds the lock.
>
>

This is one type of deadlock, not the one due to rendezvous condition,
I think. :-)

Thanks and Best Regards,

Meng

-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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