[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Wed, 2016-03-09 at 06:55 -0700, Jan Beulich wrote:
>
> > > > On 09.03.16 at 14:46, <quan.xu@xxxxxxxxx> wrote:
> > Now I am still not clear for this point- "this inconsistency might
> > lead to 
> > deadlock".
> > I think it is similar to 'mixing interrupt disabled and enabled
> > spinlocks is 
> > something we disallow'.
> > I hope you can give me an example about how to lead to deadlock. 
> The implication from disabling interrupts while acquiring a lock
> is that the lock is also being acquired by some interrupt
> handler. If you mix acquire types, the one not disabling
> interrupts is prone to be interrupted, and the interrupt trying
> to get hold of the lock the same CPU already owns.
> 
Exactly.

There are a few other nice writeup online as well.

The most famous one, I guess, is this one from Linus (look at "Lesson
3: spinlocks revisited.")
https://www.kernel.org/doc/Documentation/locking/spinlocks.txt

And, of course, there's the comment inside check_lock(), in
xen/common/spinlock.c, in Xen's codebase, where another example of how
it could be dangerous to mix, even if multiple cpus are involved.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.