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

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1631 bytes --]

On Wed, 2016-03-09 at 21:17 +0800, Quan Xu wrote:
> pcidevs_lock should be held with interrupt enabled. 
>
There's a message from Jan when he says:
<<Well, I'd say something like "pcidevs_lock doesn't require interrupts
to be disabled while being acquired".>>

:-O

> However there remains
> an exception in AMD IOMMU code, where the lock is acquired with
> interrupt
> disabled. This inconsistency might lead to deadlock.
> 
I appreciate that 'might' is weaker than 'can'. Personally, I still
dob't find this correct, or at least clear enough, referred to this
patch, but I won't be in the way because of this.

> The fix is straightforward to use spin_lock instead. Also interrupt
> has been
> enabled when this function is invoked, so we're sure consistency
> around
> pcidevs_lock can be guaranteed after this fix.
> 
And I also can't really get what "so we're sure consistency
around pcidevs_lock can be guaranteed after this fix" actually means,
but again, that's probably me, and it's fine.

However,

> Signed-off-by: Quan Xu <quan.xu@intel.com>
> Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
>
This still stands **only** if the very first sentence "pcidevs_lock
should be held with interrupt enabled" is changed to "pcidevs_lock
doesn't require interrupts to be disabled while being acquired".

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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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