[PATCH v1] iommu/amd: IRT cache incoherency bug

[PATCH v1] iommu/amd: IRT cache incoherency bug

[Magnus Kalland]

DMA aliasing causes interrupt remapping table entries (IRTEs) to be shared
between multiple device IDs. See commit 3c124435e8dd
("iommu/amd: Support multiple PCI DMA aliases in IRQ Remapping") for more
information on this. However, the AMD IOMMU driver currently invalidates
IRTE cache entries on a per-device basis whenever an IRTE is updated, not
for each alias.

This approach leaves stale IRTE cache entries when an IRTE is cached under
one DMA alias but later updated and invalidated through a different alias.
In such cases, the original device ID is never invalidated, since it is
programmed via aliasing.

This incoherency bug has been observed when IRTEs are cached for one
Non-Transparent Bridge (NTB) DMA alias, later updated via another.

Fix this by invalidating the interrupt remapping table cache for all DMA
aliases when updating an IRTE.

Link to original thread: https://lore.kernel.org/linux-iommu/20251215114952.190550-2-magnus@dolphinics.com/T/#raf80785292deb22aafe6a817424051ea0d1d28f4

Resending for visibility.

Changes since original thread:
 - Renamed struct pci_dev pointer parameter to unused
 - Rebased on latest master

Cc: Tore H. Larsen <torel@simula.no>
Co-developed-by: Lars B. Kristiansen <larsk@dolphinics.com>
Signed-off-by: Lars B. Kristiansen <larsk@dolphinics.com>
Co-developed-by: Jonas Markussen <jonas@dolphinics.com>
Signed-off-by: Jonas Markussen <jonas@dolphinics.com>
Signed-off-by: Magnus Kalland <magnus@dolphinics.com>

---
 drivers/iommu/amd/iommu.c | 30 +++++++++++++++++++++++++++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 7c12be1b247f..404afcaf4bc1 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -3103,22 +3103,44 @@ const struct iommu_ops amd_iommu_ops = {
 static struct irq_chip amd_ir_chip;
 static DEFINE_SPINLOCK(iommu_table_lock);
 
+static int iommu_flush_dev_irt(struct pci_dev *unused, u16 devid, void *data)
+{
+	int ret;
+	struct iommu_cmd cmd;
+	struct amd_iommu *iommu = data;
+
+	build_inv_irt(&cmd, devid);
+	ret = __iommu_queue_command_sync(iommu, &cmd, true);
+	return ret;
+}
+
 static void iommu_flush_irt_and_complete(struct amd_iommu *iommu, u16 devid)
 {
 	int ret;
 	u64 data;
+	int domain = iommu->pci_seg->id;
+	unsigned int bus = PCI_BUS_NUM(devid);
+	unsigned int devfn = devid & 0xff;
 	unsigned long flags;
 	struct iommu_cmd cmd, cmd2;
+	struct pci_dev *pdev = NULL;
 
 	if (iommu->irtcachedis_enabled)
 		return;
 
-	build_inv_irt(&cmd, devid);
 	data = atomic64_inc_return(&iommu->cmd_sem_val);
 	build_completion_wait(&cmd2, iommu, data);
 
-	raw_spin_lock_irqsave(&iommu->lock, flags);
-	ret = __iommu_queue_command_sync(iommu, &cmd, true);
+	pdev = pci_get_domain_bus_and_slot(domain, bus, devfn);
+	if (pdev) {
+		raw_spin_lock_irqsave(&iommu->lock, flags);
+		ret = pci_for_each_dma_alias(pdev, iommu_flush_dev_irt, iommu);
+	} else {
+		build_inv_irt(&cmd, devid);
+		raw_spin_lock_irqsave(&iommu->lock, flags);
+		ret = __iommu_queue_command_sync(iommu, &cmd, true);
+	}
+
 	if (ret)
 		goto out;
 	ret = __iommu_queue_command_sync(iommu, &cmd2, false);
@@ -3127,6 +3149,8 @@ static void iommu_flush_irt_and_complete(struct amd_iommu *iommu, u16 devid)
 	wait_on_sem(iommu, data);
 out:
 	raw_spin_unlock_irqrestore(&iommu->lock, flags);
+	if (pdev)
+		pci_dev_put(pdev);
 }
 
 static inline u8 iommu_get_int_tablen(struct iommu_dev_data *dev_data)
-- 
2.43.0

Re: [PATCH v1] iommu/amd: IRT cache incoherency bug

[Jörg Rödel]

On Tue, Feb 03, 2026 at 12:32:10PM +0100, Magnus Kalland wrote:
> DMA aliasing causes interrupt remapping table entries (IRTEs) to be shared
> between multiple device IDs. See commit 3c124435e8dd
> ("iommu/amd: Support multiple PCI DMA aliases in IRQ Remapping") for more
> information on this. However, the AMD IOMMU driver currently invalidates
> IRTE cache entries on a per-device basis whenever an IRTE is updated, not
> for each alias.
> 
> This approach leaves stale IRTE cache entries when an IRTE is cached under
> one DMA alias but later updated and invalidated through a different alias.
> In such cases, the original device ID is never invalidated, since it is
> programmed via aliasing.
> 
> This incoherency bug has been observed when IRTEs are cached for one
> Non-Transparent Bridge (NTB) DMA alias, later updated via another.
> 
> Fix this by invalidating the interrupt remapping table cache for all DMA
> aliases when updating an IRTE.
> 
> Link to original thread: https://lore.kernel.org/linux-iommu/20251215114952.190550-2-magnus@dolphinics.com/T/#raf80785292deb22aafe6a817424051ea0d1d28f4
> 
> Resending for visibility.
> 
> Changes since original thread:
>  - Renamed struct pci_dev pointer parameter to unused
>  - Rebased on latest master
> 
> Cc: Tore H. Larsen <torel@simula.no>
> Co-developed-by: Lars B. Kristiansen <larsk@dolphinics.com>
> Signed-off-by: Lars B. Kristiansen <larsk@dolphinics.com>
> Co-developed-by: Jonas Markussen <jonas@dolphinics.com>
> Signed-off-by: Jonas Markussen <jonas@dolphinics.com>
> Signed-off-by: Magnus Kalland <magnus@dolphinics.com>
> 
> ---
>  drivers/iommu/amd/iommu.c | 30 +++++++++++++++++++++++++++---
>  1 file changed, 27 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index 7c12be1b247f..404afcaf4bc1 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -3103,22 +3103,44 @@ const struct iommu_ops amd_iommu_ops = {
>  static struct irq_chip amd_ir_chip;
>  static DEFINE_SPINLOCK(iommu_table_lock);
>  
> +static int iommu_flush_dev_irt(struct pci_dev *unused, u16 devid, void *data)
> +{
> +	int ret;
> +	struct iommu_cmd cmd;
> +	struct amd_iommu *iommu = data;
> +
> +	build_inv_irt(&cmd, devid);
> +	ret = __iommu_queue_command_sync(iommu, &cmd, true);
> +	return ret;
> +}
> +
>  static void iommu_flush_irt_and_complete(struct amd_iommu *iommu, u16 devid)
>  {
>  	int ret;
>  	u64 data;
> +	int domain = iommu->pci_seg->id;
> +	unsigned int bus = PCI_BUS_NUM(devid);
> +	unsigned int devfn = devid & 0xff;
>  	unsigned long flags;
>  	struct iommu_cmd cmd, cmd2;
> +	struct pci_dev *pdev = NULL;
>  
>  	if (iommu->irtcachedis_enabled)
>  		return;
>  
> -	build_inv_irt(&cmd, devid);
>  	data = atomic64_inc_return(&iommu->cmd_sem_val);
>  	build_completion_wait(&cmd2, iommu, data);
>  
> -	raw_spin_lock_irqsave(&iommu->lock, flags);
> -	ret = __iommu_queue_command_sync(iommu, &cmd, true);
> +	pdev = pci_get_domain_bus_and_slot(domain, bus, devfn);
> +	if (pdev) {
> +		raw_spin_lock_irqsave(&iommu->lock, flags);

Move the lock above the if () ...

> +		ret = pci_for_each_dma_alias(pdev, iommu_flush_dev_irt, iommu);
> +	} else {
> +		build_inv_irt(&cmd, devid);
> +		raw_spin_lock_irqsave(&iommu->lock, flags);
> +		ret = __iommu_queue_command_sync(iommu, &cmd, true);

... and call iommu_flush_dev_irt(NULL, devid, iommu) here.

> +	}
> +
>  	if (ret)
>  		goto out;
>  	ret = __iommu_queue_command_sync(iommu, &cmd2, false);
> @@ -3127,6 +3149,8 @@ static void iommu_flush_irt_and_complete(struct amd_iommu *iommu, u16 devid)
>  	wait_on_sem(iommu, data);
>  out:
>  	raw_spin_unlock_irqrestore(&iommu->lock, flags);
> +	if (pdev)
> +		pci_dev_put(pdev);

This can also be moved to the respective if () branch above, no?

-Joerg

[PATCH v2] iommu/amd: Invalidate IRT cache for DMA aliases

[Magnus Kalland]

DMA aliasing causes interrupt remapping table entries (IRTEs) to be shared
between multiple device IDs. See commit 3c124435e8dd
("iommu/amd: Support multiple PCI DMA aliases in IRQ Remapping") for more
information on this. However, the AMD IOMMU driver currently invalidates
IRTE cache entries on a per-device basis whenever an IRTE is updated, not
for each alias.

This approach leaves stale IRTE cache entries when an IRTE is cached under
one DMA alias but later updated and invalidated through a different alias.
In such cases, the original device ID is never invalidated, since it is
programmed via aliasing.

This incoherency bug has been observed when IRTEs are cached for one
Non-Transparent Bridge (NTB) DMA alias, later updated via another.

Fix this by invalidating the interrupt remapping table cache for all DMA
aliases when updating an IRTE.

Link: https://lore.kernel.org/linux-iommu/fwtqfdk3m7qrazj4bfutl4grac46agtxztc3p2lqnejt2wyexu@lztyomxrm3pk/
Signed-off-by: Magnus Kalland <magnus@dolphinics.com>

---

v2:
 - Move the lock acquire before branching
 - Call iommu_flush_dev_irt() when pdev is null
 - Handle pdev refcount in correct branch

 drivers/iommu/amd/iommu.c | 32 +++++++++++++++++++++++++++-----
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 2e1865daa1ce..b5256b28b0c8 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -3077,25 +3077,47 @@ const struct iommu_ops amd_iommu_ops = {
 static struct irq_chip amd_ir_chip;
 static DEFINE_SPINLOCK(iommu_table_lock);
 
+static int iommu_flush_dev_irt(struct pci_dev *unused, u16 devid, void *data)
+{
+	int ret;
+	struct iommu_cmd cmd;
+	struct amd_iommu *iommu = data;
+
+	build_inv_irt(&cmd, devid);
+	ret = __iommu_queue_command_sync(iommu, &cmd, true);
+	return ret;
+}
+
 static void iommu_flush_irt_and_complete(struct amd_iommu *iommu, u16 devid)
 {
 	int ret;
 	u64 data;
+	int domain = iommu->pci_seg->id;
+	unsigned int bus = PCI_BUS_NUM(devid);
+	unsigned int devfn = devid & 0xff;
 	unsigned long flags;
-	struct iommu_cmd cmd, cmd2;
+	struct iommu_cmd cmd;
+	struct pci_dev *pdev = NULL;
 
 	if (iommu->irtcachedis_enabled)
 		return;
 
-	build_inv_irt(&cmd, devid);
 	data = atomic64_inc_return(&iommu->cmd_sem_val);
-	build_completion_wait(&cmd2, iommu, data);
+	build_completion_wait(&cmd, iommu, data);
 
+	pdev = pci_get_domain_bus_and_slot(domain, bus, devfn);
 	raw_spin_lock_irqsave(&iommu->lock, flags);
-	ret = __iommu_queue_command_sync(iommu, &cmd, true);
+	if (pdev) {
+		ret = pci_for_each_dma_alias(pdev, iommu_flush_dev_irt, iommu);
+		pci_dev_put(pdev);
+	} else {
+		ret = iommu_flush_dev_irt(NULL, devid, iommu);
+	}
+
 	if (ret)
 		goto out;
-	ret = __iommu_queue_command_sync(iommu, &cmd2, false);
+
+	ret = __iommu_queue_command_sync(iommu, &cmd, false);
 	if (ret)
 		goto out;
 	wait_on_sem(iommu, data);
-- 
2.43.0

Re: [PATCH v2] iommu/amd: Invalidate IRT cache for DMA aliases

[Jörg Rödel]

On Thu, Feb 05, 2026 at 03:01:00PM +0100, Magnus Kalland wrote:
>  drivers/iommu/amd/iommu.c | 32 +++++++++++++++++++++++++++-----
>  1 file changed, 27 insertions(+), 5 deletions(-)

This does not apply cleanly on the iommu/next branch or the iommu/amd/amd-vi
branch. Please rebase to the next -rc1 when it comes out and re-send.

-Joerg

Re: [PATCH v2] iommu/amd: Invalidate IRT cache for DMA aliases

[Vasant Hegde]

Joerg,

On 2/6/2026 3:36 PM, Jörg Rödel wrote:
> On Thu, Feb 05, 2026 at 03:01:00PM +0100, Magnus Kalland wrote:
>>  drivers/iommu/amd/iommu.c | 32 +++++++++++++++++++++++++++-----
>>  1 file changed, 27 insertions(+), 5 deletions(-)
> 
> This does not apply cleanly on the iommu/next branch or the iommu/amd/amd-vi
> branch. Please rebase to the next -rc1 when it comes out and re-send.

Sorry. I had missed this one. Patch looks fine. Can you wait until Monday? We
want to test it internally and make sure it looks fine.

-Vasant

Re: [PATCH v2] iommu/amd: Invalidate IRT cache for DMA aliases

[Jörg Rödel]

Hi Vasant,

On Fri, Feb 06, 2026 at 03:40:49PM +0530, Vasant Hegde wrote:
> On 2/6/2026 3:36 PM, Jörg Rödel wrote:
> > On Thu, Feb 05, 2026 at 03:01:00PM +0100, Magnus Kalland wrote:
> >>  drivers/iommu/amd/iommu.c | 32 +++++++++++++++++++++++++++-----
> >>  1 file changed, 27 insertions(+), 5 deletions(-)
> > 
> > This does not apply cleanly on the iommu/next branch or the iommu/amd/amd-vi
> > branch. Please rebase to the next -rc1 when it comes out and re-send.
> 
> Sorry. I had missed this one. Patch looks fine. Can you wait until Monday? We
> want to test it internally and make sure it looks fine.

You have at least two more weeks, this will not make it into my tree until
after the next merge window.

-Joerg

Re: [PATCH v2] iommu/amd: Invalidate IRT cache for DMA aliases

[Srivastava, Dheeraj Kumar]

Hi Magnus,

On 2/5/2026 7:31 PM, Magnus Kalland wrote:
> DMA aliasing causes interrupt remapping table entries (IRTEs) to be shared
> between multiple device IDs. See commit 3c124435e8dd
> ("iommu/amd: Support multiple PCI DMA aliases in IRQ Remapping") for more
> information on this. However, the AMD IOMMU driver currently invalidates
> IRTE cache entries on a per-device basis whenever an IRTE is updated, not
> for each alias.
> 
> This approach leaves stale IRTE cache entries when an IRTE is cached under
> one DMA alias but later updated and invalidated through a different alias.
> In such cases, the original device ID is never invalidated, since it is
> programmed via aliasing.
> 
> This incoherency bug has been observed when IRTEs are cached for one
> Non-Transparent Bridge (NTB) DMA alias, later updated via another.
> 
> Fix this by invalidating the interrupt remapping table cache for all DMA
> aliases when updating an IRTE.
> 
> Link: https://lore.kernel.org/linux-iommu/fwtqfdk3m7qrazj4bfutl4grac46agtxztc3p2lqnejt2wyexu@lztyomxrm3pk/
> Signed-off-by: Magnus Kalland <magnus@dolphinics.com>
> 
> ---
> 
> v2:
>   - Move the lock acquire before branching
>   - Call iommu_flush_dev_irt() when pdev is null
>   - Handle pdev refcount in correct branch
> 
>   drivers/iommu/amd/iommu.c | 32 +++++++++++++++++++++++++++-----
>   1 file changed, 27 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index 2e1865daa1ce..b5256b28b0c8 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -3077,25 +3077,47 @@ const struct iommu_ops amd_iommu_ops = {
>   static struct irq_chip amd_ir_chip;
>   static DEFINE_SPINLOCK(iommu_table_lock);
>   
> +static int iommu_flush_dev_irt(struct pci_dev *unused, u16 devid, void *data)
> +{
> +	int ret;
> +	struct iommu_cmd cmd;
> +	struct amd_iommu *iommu = data;
> +
> +	build_inv_irt(&cmd, devid);
> +	ret = __iommu_queue_command_sync(iommu, &cmd, true);
> +	return ret;
> +}
> +
>   static void iommu_flush_irt_and_complete(struct amd_iommu *iommu, u16 devid)
>   {
>   	int ret;
>   	u64 data;
> +	int domain = iommu->pci_seg->id;
> +	unsigned int bus = PCI_BUS_NUM(devid);
> +	unsigned int devfn = devid & 0xff;
>   	unsigned long flags;
> -	struct iommu_cmd cmd, cmd2;
> +	struct iommu_cmd cmd;
> +	struct pci_dev *pdev = NULL;
>   
>   	if (iommu->irtcachedis_enabled)
>   		return;
>   
> -	build_inv_irt(&cmd, devid);
>   	data = atomic64_inc_return(&iommu->cmd_sem_val);
> -	build_completion_wait(&cmd2, iommu, data);
> +	build_completion_wait(&cmd, iommu, data);
>   
> +	pdev = pci_get_domain_bus_and_slot(domain, bus, devfn);
>   	raw_spin_lock_irqsave(&iommu->lock, flags);
> -	ret = __iommu_queue_command_sync(iommu, &cmd, true);
> +	if (pdev) {
> +		ret = pci_for_each_dma_alias(pdev, iommu_flush_dev_irt, iommu);
> +		pci_dev_put(pdev);
> +	} else {
> +		ret = iommu_flush_dev_irt(NULL, devid, iommu);
> +	}
> +
>   	if (ret)
>   		goto out;
> -	ret = __iommu_queue_command_sync(iommu, &cmd2, false);
> +
> +	ret = __iommu_queue_command_sync(iommu, &cmd, false);
>   	if (ret)
>   		goto out;
>   	wait_on_sem(iommu, data);


I tested the patch with lockdep (CONFIG_PROVE_LOCKING=y) enabled and 
observed the following lockdep warnings in the kernel logs.

[    7.215360] kernel: =============================
[    7.215360] kernel: [ BUG: Invalid wait context ]
[    7.215360] kernel: 6.19.0-rc8-3e36d27b34eb-1770495763816 #1 Not tainted
[    7.215360] kernel: -----------------------------
[    7.215360] kernel: swapper/0/1 is trying to lock:
[    7.215360] kernel: ff4a3b3365f62368 (&k->list_lock){+.+.}-{3:3}, at: 
bus_to_subsys+0x28/0x90
[    7.215360] kernel: other info that might help us debug this:
[    7.215360] kernel: context-{5:5}
[    7.215360] kernel: 2 locks held by swapper/0/1:
[    7.215360] kernel:  #0: ff4a3ad400055650 
(&desc->request_mutex){+.+.}-{4:4}, at: __setup_irq+0xac/0x770
[    7.215360] kernel:  #1: ff4a3ad4000554c0 
(&irq_desc_lock_class){-...}-{2:2}, at: __setup_irq+0xe7/0x770
[    7.215360] kernel: stack backtrace:
[    7.215360] kernel: CPU: 61 UID: 0 PID: 1 Comm: swapper/0 Not tainted 
6.19.0-rc8-3e36d27b34eb-1770495763816 #1 PREEMPT(voluntary)
[    7.215360] kernel: Hardware name: AMD Corporation 
Titanite_4G/Titanite_4G, BIOS RTI100CC 03/28/2024
[    7.215360] kernel: Call Trace:
[    7.215360] kernel:  <TASK>
[    7.215360] kernel:  dump_stack_lvl+0x78/0xe0
[    7.215360] kernel:  __lock_acquire+0x836/0xbe0
[    7.215360] kernel:  lock_acquire+0xc7/0x2c0
[    7.215360] kernel:  ? bus_to_subsys+0x28/0x90
[    7.215360] kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
[    7.215360] kernel:  ? validate_chain+0x261/0x6e0
[    7.215360] kernel:  ? __pfx_match_pci_dev_by_id+0x10/0x10
[    7.215360] kernel:  _raw_spin_lock+0x34/0x80
[    7.215360] kernel:  ? bus_to_subsys+0x28/0x90
[    7.215360] kernel:  bus_to_subsys+0x28/0x90
[    7.215360] kernel:  bus_find_device+0x30/0xd0
[    7.215360] kernel:  ? lock_acquire+0xc7/0x2c0
[    7.215360] kernel:  pci_get_domain_bus_and_slot+0x7d/0x100
[    7.215360] kernel:  iommu_flush_irt_and_complete+0xaa/0x190
[    7.215360] kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
[    7.215360] kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
[    7.215360] kernel:  ? __modify_irte_ga.isra.0+0x5f/0x80
[    7.215360] kernel:  irq_remapping_activate+0x43/0x80
[    7.215360] kernel:  __irq_domain_activate_irq+0x53/0x90
[    7.215360] kernel:  __irq_domain_activate_irq+0x32/0x90
[    7.215360] kernel:  irq_domain_activate_irq+0x2d/0x50
[    7.215360] kernel:  __setup_irq+0x339/0x770
[    7.215360] kernel:  request_threaded_irq+0xe5/0x190
[    7.215360] kernel:  ? __pfx_acpi_irq+0x10/0x10
[    7.215360] kernel:  ? __pfx_acpi_ev_sci_xrupt_handler+0x10/0x10
[    7.215360] kernel:  acpi_os_install_interrupt_handler+0xaf/0x100
[    7.215360] kernel:  ? __pfx_acpi_init+0x10/0x10
[    7.215360] kernel:  acpi_ev_install_xrupt_handlers+0x22/0x90
[    7.215360] kernel:  ? __pfx_acpi_init+0x10/0x10
[    7.215360] kernel:  acpi_bus_init+0x3a/0x460
[    7.215360] kernel:  ? acpi_ut_release_mutex+0x4a/0x90
[    7.215360] kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
[    7.215360] kernel:  ? 
acpi_install_address_space_handler_internal.part.0+0x64/0x90
[    7.215360] kernel:  ? __pfx_acpi_init+0x10/0x10
[    7.215360] kernel:  ? __pfx_acpi_init+0x10/0x10
[    7.215360] kernel:  acpi_init+0x5d/0x130
[    7.215360] kernel:  ? __pfx_scan_for_dmi_ipmi+0x10/0x10
[    7.215360] kernel:  ? __pfx_acpi_init+0x10/0x10
[    7.215360] kernel:  do_one_initcall+0x5c/0x370
[    7.215360] kernel:  do_initcalls+0xdb/0x190
[    7.215360] kernel:  kernel_init_freeable+0x2d1/0x420
[    7.215360] kernel:  ? __pfx_kernel_init+0x10/0x10
[    7.215360] kernel:  kernel_init+0x1a/0x1c0
[    7.215360] kernel:  ret_from_fork+0x25a/0x280
[    7.215360] kernel:  ? __pfx_kernel_init+0x10/0x10
[    7.215360] kernel:  ret_from_fork_asm+0x1a/0x30
[    7.215360] kernel:  </TASK>

 From the warning trace, it appears that __setup_irq() is already 
holding a raw_spinlock (context 2).

Meanwhile, pci_get_domain_bus_and_slot() attempts to acquire a regular 
spinlock (context 3). This triggers the kernel warning.

Thanks
Dheeraj