[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 March 09, 2016 10:45pm, Dario Faggioli wrote:
> 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.
> 
Dario, thanks! You know, it helped me a lot.

Quan

_______________________________________________
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®.