[PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free

[PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free

[Shawn Lin]

This patch series addresses a long-standing design issue in the PCI/MSI
subsystem where the implicit, automatic management of IRQ vectors by
the devres framework conflicts with explicit driver cleanup, creating
ambiguity and potential resource management bugs.

==== The Problem: Implicit vs. Explicit Management ====
Historically, `pcim_enable_device()` not only manages standard PCI resources
(BARs) via devres but also implicitly triggers automatic IRQ vector management
by setting a flag that registers `pcim_msi_release()` as a cleanup action.

This creates an ambiguous ownership model. Many drivers follow a pattern of:
1. Calling `pci_alloc_irq_vectors()` to allocate interrupts.
2. Also calling `pci_free_irq_vectors()` in their error paths or remove routines.

When such a driver also uses `pcim_enable_device()`, the devres framework may
attempt to free the IRQ vectors a second time upon device release, leading to
a double-free. Analysis of the tree shows this hazardous pattern exists widely,
while 35 other drivers correctly rely solely on the implicit cleanup.

==== The Solution: Making Management Explicit ====
This series enforces a clear, predictable model:
1.  New Managed API (Patch 1/37): Introduces pcim_alloc_irq_vectors() and
    pcim_alloc_irq_vectors_affinity(). Drivers that desire devres-managed IRQ
    vectors should use these functions, which set the is_msi_managed flag and
    ensure automatic cleanup.
2.  Patches 2 through 36 convert each driver that uses pcim_enable_device() alongside
    pci_alloc_irq_vectors() and relies on devres for IRQ vector cleanup to instead
    make an explicit call to pcim_alloc_irq_vectors().
3.  Core Change (Patch 37/37): With the former cleanup, now modifies pcim_setup_msi_release()
    to check only the is_msi_managed flag. This decouples automatic IRQ cleanup from
    pcim_enable_device(). IRQ vectors allocated via pci_alloc_irq_vectors*()
    are now solely the driver's responsibility to free with pci_free_irq_vectors().

With these changes, we clear ownership model: Explicit resource management eliminates
ambiguity and follows the "principle of least surprise." New drivers choose one model and
be consistent.
- Use `pci_alloc_irq_vectors()` + `pci_free_irq_vectors()` for explicit control.
- Use `pcim_alloc_irq_vectors()` for devres-managed, automatic cleanup.

==== Testing And Review ====
1. This series is only compiled test with allmodconfig.
2. Given the substantial size of this patch series, I have structured the mailing
   to facilitate efficient review. The cover letter, the first patch and the last one will be sent
   to all relevant mailing lists and key maintainers to ensure broad visibility and
   initial feedback on the overall approach. The remaining subsystem-specific patches
   will be sent only to the respective subsystem maintainers and their associated
   mailing lists, reducing noise.

Please help review it, much thanks!



Shawn Lin (37):
  PCI/MSI: Add Devres managed IRQ vectors allocation
  mmc: cavium: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  media: ipu6: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  gpio: merrifield: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  PCI: switchtec: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  PCI: vmd: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  spi: spi-pci1xxxx: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  spi: pxa2xx: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  i2c: amd-mp2: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  i2c: mchp-pci1xxxx: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  i2c: thunderx: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  i2c: designware: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  bus: mhi: host: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  serial: 8250_mid: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  serial: 8250_exar: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  platform/x86/intel: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  crypto: safexcel: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  crypto: octeontx2: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  cxl/pci: Replace pci_alloc_irq_vectors() with pcim_alloc_irq_vectors()
  drm/hisilicon/hibmc: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  iommu/riscv: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  thunderbolt: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  accel/amdxdna: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  accel/ivpu: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  accel/qaic: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  net: stmmac: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  r8169: Replace pci_alloc_irq_vectors() with pcim_alloc_irq_vectors()
  net: thunder_bgx: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  net: hibmcge: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  mfd: intel-lpss: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  dmaengine: hsu: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  dmaengine: hisilicon: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  i3c: mipi-i3c-hci-pci: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  HID: intel-ish-ipc: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  HID: Intel-thc-hid: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  misc: microchip: pci1xxxx: Replace pci_alloc_irq_vectors() with
    pcim_alloc_irq_vectors()
  PCI/MSI: Only check is_msi_managed in pcim_setup_msi_release()

 drivers/accel/amdxdna/aie2_pci.c                   |  2 +-
 drivers/accel/ivpu/ivpu_drv.c                      |  2 +-
 drivers/accel/qaic/qaic_drv.c                      |  4 ++--
 drivers/bus/mhi/host/pci_generic.c                 |  3 ++-
 drivers/crypto/inside-secure/safexcel.c            |  8 +++----
 drivers/crypto/marvell/octeontx2/otx2_cptpf_main.c |  2 +-
 drivers/crypto/marvell/octeontx2/otx2_cptvf_main.c |  4 ++--
 drivers/cxl/pci.c                                  |  8 ++-----
 drivers/dma/hisi_dma.c                             |  3 +--
 drivers/dma/hsu/pci.c                              |  2 +-
 drivers/gpio/gpio-merrifield.c                     |  2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c    |  4 ++--
 drivers/hid/intel-ish-hid/ipc/pci-ish.c            |  2 +-
 .../intel-thc-hid/intel-quicki2c/pci-quicki2c.c    |  2 +-
 drivers/i2c/busses/i2c-amd-mp2-pci.c               |  2 +-
 drivers/i2c/busses/i2c-designware-pcidrv.c         |  2 +-
 drivers/i2c/busses/i2c-mchp-pci1xxxx.c             |  2 +-
 drivers/i2c/busses/i2c-thunderx-pcidrv.c           |  2 +-
 drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-pci.c |  2 +-
 drivers/iommu/riscv/iommu-pci.c                    |  4 ++--
 drivers/media/pci/intel/ipu6/ipu6.c                |  2 +-
 drivers/mfd/intel-lpss-pci.c                       |  2 +-
 drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c      |  2 +-
 drivers/mmc/host/cavium-thunderx.c                 |  2 +-
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c  |  4 ++--
 drivers/net/ethernet/hisilicon/hibmcge/hbg_irq.c   |  4 ++--
 drivers/net/ethernet/realtek/r8169_main.c          |  2 +-
 drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c  |  6 ++---
 drivers/pci/controller/vmd.c                       |  4 ++--
 drivers/pci/msi/api.c                              | 26 ++++++++++++++++++++++
 drivers/pci/msi/msi.c                              |  4 +---
 drivers/pci/switch/switchtec.c                     |  6 ++---
 drivers/platform/x86/intel/ehl_pse_io.c            |  2 +-
 drivers/spi/spi-pci1xxxx.c                         |  4 ++--
 drivers/spi/spi-pxa2xx-pci.c                       |  2 +-
 drivers/thunderbolt/nhi.c                          |  6 ++---
 drivers/tty/serial/8250/8250_exar.c                |  2 +-
 drivers/tty/serial/8250/8250_mid.c                 |  2 +-
 include/linux/pci.h                                | 22 ++++++++++++++++++
 39 files changed, 104 insertions(+), 62 deletions(-)

-- 
2.7.4

[PATCH 01/37] PCI/MSI: Add Devres managed IRQ vectors allocation

[Shawn Lin]

pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for
pci device drivers which rely on the devres machinery to help cleanup the IRQ
vectors.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
---

 drivers/pci/msi/api.c | 26 ++++++++++++++++++++++++++
 include/linux/pci.h   | 22 ++++++++++++++++++++++
 2 files changed, 48 insertions(+)

diff --git a/drivers/pci/msi/api.c b/drivers/pci/msi/api.c
index c18559b..2362fca 100644
--- a/drivers/pci/msi/api.c
+++ b/drivers/pci/msi/api.c
@@ -297,6 +297,32 @@ int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
 EXPORT_SYMBOL(pci_alloc_irq_vectors_affinity);
 
 /**
+ * pcim_alloc_irq_vectors() - devres managed pci_alloc_irq_vectors()
+ * Interrupt vectors are automatically freed by the devres machinery
+ */
+int pcim_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
+			   unsigned int max_vecs, unsigned int flags)
+{
+	return pcim_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,
+					       flags, NULL);
+}
+EXPORT_SYMBOL(pcim_alloc_irq_vectors);
+
+/**
+ * pcim_alloc_irq_vectors_affinity() - devres managed pci_alloc_irq_vectors_affinity()
+ * Interrupt vectors are automatically freed by the devres machinery
+ */
+int pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
+				   unsigned int max_vecs, unsigned int flags,
+				   struct irq_affinity *affd)
+{
+	dev->is_msi_managed = true;
+	return pci_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,
+					      flags, affd);
+}
+EXPORT_SYMBOL(pcim_alloc_irq_vectors_affinity);
+
+/**
  * pci_irq_vector() - Get Linux IRQ number of a device interrupt vector
  * @dev: the PCI device to operate on
  * @nr:  device-relative interrupt vector index (0-based); has different
diff --git a/include/linux/pci.h b/include/linux/pci.h
index d5ec0f8..ae58f70 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1764,6 +1764,12 @@ int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
 				   unsigned int max_vecs, unsigned int flags,
 				   struct irq_affinity *affd);
 
+int pcim_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
+			  unsigned int max_vecs, unsigned int flags);
+int pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
+				   unsigned int max_vecs, unsigned int flags,
+				   struct irq_affinity *affd);
+
 bool pci_msix_can_alloc_dyn(struct pci_dev *dev);
 struct msi_map pci_msix_alloc_irq_at(struct pci_dev *dev, unsigned int index,
 				     const struct irq_affinity_desc *affdesc);
@@ -1806,6 +1812,22 @@ pci_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
 					      flags, NULL);
 }
 
+static inline int
+pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
+			       unsigned int max_vecs, unsigned int flags,
+			       struct irq_affinity *aff_desc)
+{
+	return pci_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,
+					      flags, aff_desc);
+}
+static inline int
+pcim_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
+		      unsigned int max_vecs, unsigned int flags)
+{
+	return pcim_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,
+					      flags, NULL);
+}
+
 static inline bool pci_msix_can_alloc_dyn(struct pci_dev *dev)
 { return false; }
 static inline struct msi_map pci_msix_alloc_irq_at(struct pci_dev *dev, unsigned int index,
-- 
2.7.4

[PATCH 37/37] PCI/MSI: Only check is_msi_managed in pcim_setup_msi_release()

[Shawn Lin]

The function pcim_enable_device() sets the is_managed flag, which
causes the device's IRQ vectors to be automatically managed and released
by the devres framework. If a driver subsequently calls
pci_free_irq_vectors() manually, it can lead to a double-free of the
interrupt resources.

Analysis reveals most PCI drivers call pci_free_irq_vectors()
while also using pcim_enable_device(), making them susceptible to this
double-free issue. In contrast, 35 drivers follow the pattern of
relying on devres to handle the cleanup.

To address this inconsistency and enforce explicit, driver-managed
control of IRQ vectors, this patch removes the pci_is_managed() check
from pcim_setup_msi_release() and let devres help cleanup if is_msi_managed
is true. This change ensures that interrupt vectors are not automatically
freed by the devres machinery when pcim_enable_device() is used, placing
the responsibility for their release squarely on the driver logic via
pci_free_irq_vectors(). If the driver need devres to help cleanup, newly added
pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() helpers could be used.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>

---

 drivers/pci/msi/msi.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/pci/msi/msi.c b/drivers/pci/msi/msi.c
index 81d24a2..0727a0a 100644
--- a/drivers/pci/msi/msi.c
+++ b/drivers/pci/msi/msi.c
@@ -70,7 +70,6 @@ static void pcim_msi_release(void *pcidev)
 {
 	struct pci_dev *dev = pcidev;
 
-	dev->is_msi_managed = false;
 	pci_free_irq_vectors(dev);
 }
 
@@ -92,14 +91,13 @@ static int pcim_setup_msi_release(struct pci_dev *dev)
 {
 	int ret;
 
-	if (!pci_is_managed(dev) || dev->is_msi_managed)
+	if (!dev->is_msi_managed)
 		return 0;
 
 	ret = devm_add_action(&dev->dev, pcim_msi_release, dev);
 	if (ret)
 		return ret;
 
-	dev->is_msi_managed = true;
 	return 0;
 }
 
-- 
2.7.4

[PATCH 03/37] media: ipu6: Replace pci_alloc_irq_vectors() with pcim_alloc_irq_vectors()

[Shawn Lin]

pcim_enable_device() no longer automatically manages IRQ vectors via devres.
Drivers must now manually call pci_free_irq_vectors() for cleanup. Alternatively,
pcim_alloc_irq_vectors() should be used.

To: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Bingbu Cao <bingbu.cao@intel.com>
To: Tianshu Qiu <tian.shu.qiu@intel.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: linux-media@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Philipp Stanner <phasta@kernel.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
---

 drivers/media/pci/intel/ipu6/ipu6.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/pci/intel/ipu6/ipu6.c b/drivers/media/pci/intel/ipu6/ipu6.c
index 24238f8..6ab94db 100644
--- a/drivers/media/pci/intel/ipu6/ipu6.c
+++ b/drivers/media/pci/intel/ipu6/ipu6.c
@@ -471,7 +471,7 @@ static int ipu6_pci_config_setup(struct pci_dev *dev, u8 hw_ver)
 		return 0;
 	}
 
-	ret = pci_alloc_irq_vectors(dev, 1, 1, PCI_IRQ_MSI);
+	ret = pcim_alloc_irq_vectors(dev, 1, 1, PCI_IRQ_MSI);
 	if (ret < 0)
 		return dev_err_probe(&dev->dev, ret, "Request msi failed");
 
-- 
2.7.4

Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free

[Andy Shevchenko]

On Mon, Feb 23, 2026 at 5:32 PM Shawn Lin <shawn.lin@rock-chips.com> wrote:
>
> This patch series addresses a long-standing design issue in the PCI/MSI
> subsystem where the implicit, automatic management of IRQ vectors by
> the devres framework conflicts with explicit driver cleanup, creating
> ambiguity and potential resource management bugs.
>
> ==== The Problem: Implicit vs. Explicit Management ====
> Historically, `pcim_enable_device()` not only manages standard PCI resources
> (BARs) via devres but also implicitly triggers automatic IRQ vector management
> by setting a flag that registers `pcim_msi_release()` as a cleanup action.
>
> This creates an ambiguous ownership model. Many drivers follow a pattern of:
> 1. Calling `pci_alloc_irq_vectors()` to allocate interrupts.
> 2. Also calling `pci_free_irq_vectors()` in their error paths or remove routines.
>
> When such a driver also uses `pcim_enable_device()`, the devres framework may
> attempt to free the IRQ vectors a second time upon device release, leading to
> a double-free. Analysis of the tree shows this hazardous pattern exists widely,
> while 35 other drivers correctly rely solely on the implicit cleanup.

Is this confirmed? What I read from the cover letter, this series was
only compile-tested, so how can you prove the problem exists in the
first place?

> ==== The Solution: Making Management Explicit ====
> This series enforces a clear, predictable model:
> 1.  New Managed API (Patch 1/37): Introduces pcim_alloc_irq_vectors() and
>     pcim_alloc_irq_vectors_affinity(). Drivers that desire devres-managed IRQ
>     vectors should use these functions, which set the is_msi_managed flag and
>     ensure automatic cleanup.
> 2.  Patches 2 through 36 convert each driver that uses pcim_enable_device() alongside
>     pci_alloc_irq_vectors() and relies on devres for IRQ vector cleanup to instead
>     make an explicit call to pcim_alloc_irq_vectors().
> 3.  Core Change (Patch 37/37): With the former cleanup, now modifies pcim_setup_msi_release()
>     to check only the is_msi_managed flag. This decouples automatic IRQ cleanup from
>     pcim_enable_device(). IRQ vectors allocated via pci_alloc_irq_vectors*()
>     are now solely the driver's responsibility to free with pci_free_irq_vectors().
>
> With these changes, we clear ownership model: Explicit resource management eliminates
> ambiguity and follows the "principle of least surprise." New drivers choose one model and
> be consistent.
> - Use `pci_alloc_irq_vectors()` + `pci_free_irq_vectors()` for explicit control.
> - Use `pcim_alloc_irq_vectors()` for devres-managed, automatic cleanup.

Have you checked previous attempts? Why is your series better than those?

> ==== Testing And Review ====
> 1. This series is only compiled test with allmodconfig.
> 2. Given the substantial size of this patch series, I have structured the mailing
>    to facilitate efficient review. The cover letter, the first patch and the last one will be sent
>    to all relevant mailing lists and key maintainers to ensure broad visibility and
>    initial feedback on the overall approach. The remaining subsystem-specific patches
>    will be sent only to the respective subsystem maintainers and their associated
>    mailing lists, reducing noise.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free

[Shawn Lin]

Hi Andy

在 2026/02/23 星期一 23:50, Andy Shevchenko 写道:
> On Mon, Feb 23, 2026 at 5:32 PM Shawn Lin <shawn.lin@rock-chips.com> wrote:
>>
>> This patch series addresses a long-standing design issue in the PCI/MSI
>> subsystem where the implicit, automatic management of IRQ vectors by
>> the devres framework conflicts with explicit driver cleanup, creating
>> ambiguity and potential resource management bugs.
>>
>> ==== The Problem: Implicit vs. Explicit Management ====
>> Historically, `pcim_enable_device()` not only manages standard PCI resources
>> (BARs) via devres but also implicitly triggers automatic IRQ vector management
>> by setting a flag that registers `pcim_msi_release()` as a cleanup action.
>>
>> This creates an ambiguous ownership model. Many drivers follow a pattern of:
>> 1. Calling `pci_alloc_irq_vectors()` to allocate interrupts.
>> 2. Also calling `pci_free_irq_vectors()` in their error paths or remove routines.
>>
>> When such a driver also uses `pcim_enable_device()`, the devres framework may
>> attempt to free the IRQ vectors a second time upon device release, leading to
>> a double-free. Analysis of the tree shows this hazardous pattern exists widely,
>> while 35 other drivers correctly rely solely on the implicit cleanup.
> 
> Is this confirmed? What I read from the cover letter, this series was
> only compile-tested, so how can you prove the problem exists in the
> first place?

Yes, it's confirmed. My debug of a double free issue of a out-of-tree
PCIe wifi driver which uses
pcim_enable_device + pci_alloc_irq_vectors + pci_free_irq_vectors expose
it. And we did have a TODO to cleanup this hybrid usage, targeted in
this cycle[1] suggested by Philipp:

[1] https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=msi

> 
>> ==== The Solution: Making Management Explicit ====
>> This series enforces a clear, predictable model:
>> 1.  New Managed API (Patch 1/37): Introduces pcim_alloc_irq_vectors() and
>>      pcim_alloc_irq_vectors_affinity(). Drivers that desire devres-managed IRQ
>>      vectors should use these functions, which set the is_msi_managed flag and
>>      ensure automatic cleanup.
>> 2.  Patches 2 through 36 convert each driver that uses pcim_enable_device() alongside
>>      pci_alloc_irq_vectors() and relies on devres for IRQ vector cleanup to instead
>>      make an explicit call to pcim_alloc_irq_vectors().
>> 3.  Core Change (Patch 37/37): With the former cleanup, now modifies pcim_setup_msi_release()
>>      to check only the is_msi_managed flag. This decouples automatic IRQ cleanup from
>>      pcim_enable_device(). IRQ vectors allocated via pci_alloc_irq_vectors*()
>>      are now solely the driver's responsibility to free with pci_free_irq_vectors().
>>
>> With these changes, we clear ownership model: Explicit resource management eliminates
>> ambiguity and follows the "principle of least surprise." New drivers choose one model and
>> be consistent.
>> - Use `pci_alloc_irq_vectors()` + `pci_free_irq_vectors()` for explicit control.
>> - Use `pcim_alloc_irq_vectors()` for devres-managed, automatic cleanup.
> 
> Have you checked previous attempts? Why is your series better than those?

There seems not previous attempts.

> 
>> ==== Testing And Review ====
>> 1. This series is only compiled test with allmodconfig.
>> 2. Given the substantial size of this patch series, I have structured the mailing
>>     to facilitate efficient review. The cover letter, the first patch and the last one will be sent
>>     to all relevant mailing lists and key maintainers to ensure broad visibility and
>>     initial feedback on the overall approach. The remaining subsystem-specific patches
>>     will be sent only to the respective subsystem maintainers and their associated
>>     mailing lists, reducing noise.
> 

Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free

[Andy Shevchenko]

On Tue, Feb 24, 2026 at 12:09:37AM +0800, Shawn Lin wrote:
> 在 2026/02/23 星期一 23:50, Andy Shevchenko 写道:
> > On Mon, Feb 23, 2026 at 5:32 PM Shawn Lin <shawn.lin@rock-chips.com> wrote:
> > > 
> > > This patch series addresses a long-standing design issue in the PCI/MSI
> > > subsystem where the implicit, automatic management of IRQ vectors by
> > > the devres framework conflicts with explicit driver cleanup, creating
> > > ambiguity and potential resource management bugs.
> > > 
> > > ==== The Problem: Implicit vs. Explicit Management ====
> > > Historically, `pcim_enable_device()` not only manages standard PCI resources
> > > (BARs) via devres but also implicitly triggers automatic IRQ vector management
> > > by setting a flag that registers `pcim_msi_release()` as a cleanup action.
> > > 
> > > This creates an ambiguous ownership model. Many drivers follow a pattern of:
> > > 1. Calling `pci_alloc_irq_vectors()` to allocate interrupts.
> > > 2. Also calling `pci_free_irq_vectors()` in their error paths or remove routines.
> > > 
> > > When such a driver also uses `pcim_enable_device()`, the devres framework may
> > > attempt to free the IRQ vectors a second time upon device release, leading to
> > > a double-free. Analysis of the tree shows this hazardous pattern exists widely,
> > > while 35 other drivers correctly rely solely on the implicit cleanup.
> > 
> > Is this confirmed? What I read from the cover letter, this series was
> > only compile-tested, so how can you prove the problem exists in the
> > first place?
> 
> Yes, it's confirmed. My debug of a double free issue of a out-of-tree
> PCIe wifi driver which uses
> pcim_enable_device + pci_alloc_irq_vectors + pci_free_irq_vectors expose
> it. And we did have a TODO to cleanup this hybrid usage, targeted in
> this cycle[1] suggested by Philipp:

Okay, fair enough. I think this bit was missing in the cover letter.

> [1] https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=msi

> > > ==== The Solution: Making Management Explicit ====
> > > This series enforces a clear, predictable model:
> > > 1.  New Managed API (Patch 1/37): Introduces pcim_alloc_irq_vectors() and
> > >      pcim_alloc_irq_vectors_affinity(). Drivers that desire devres-managed IRQ
> > >      vectors should use these functions, which set the is_msi_managed flag and
> > >      ensure automatic cleanup.
> > > 2.  Patches 2 through 36 convert each driver that uses pcim_enable_device() alongside
> > >      pci_alloc_irq_vectors() and relies on devres for IRQ vector cleanup to instead
> > >      make an explicit call to pcim_alloc_irq_vectors().
> > > 3.  Core Change (Patch 37/37): With the former cleanup, now modifies pcim_setup_msi_release()
> > >      to check only the is_msi_managed flag. This decouples automatic IRQ cleanup from
> > >      pcim_enable_device(). IRQ vectors allocated via pci_alloc_irq_vectors*()
> > >      are now solely the driver's responsibility to free with pci_free_irq_vectors().
> > > 
> > > With these changes, we clear ownership model: Explicit resource management eliminates
> > > ambiguity and follows the "principle of least surprise." New drivers choose one model and
> > > be consistent.
> > > - Use `pci_alloc_irq_vectors()` + `pci_free_irq_vectors()` for explicit control.
> > > - Use `pcim_alloc_irq_vectors()` for devres-managed, automatic cleanup.
> > 
> > Have you checked previous attempts? Why is your series better than those?
> 
> There seems not previous attempts.

Maybe we are looking to the different projects...

https://lore.kernel.org/all/?q=pcim_alloc_irq_vectors

> > > ==== Testing And Review ====
> > > 1. This series is only compiled test with allmodconfig.
> > > 2. Given the substantial size of this patch series, I have structured the mailing
> > >     to facilitate efficient review. The cover letter, the first patch and the last one will be sent
> > >     to all relevant mailing lists and key maintainers to ensure broad visibility and
> > >     initial feedback on the overall approach. The remaining subsystem-specific patches
> > >     will be sent only to the respective subsystem maintainers and their associated
> > >     mailing lists, reducing noise.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 01/37] PCI/MSI: Add Devres managed IRQ vectors allocation

[Jakub Kicinski]

On Mon, 23 Feb 2026 23:29:40 +0800 Shawn Lin wrote:
> pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for
> pci device drivers which rely on the devres machinery to help cleanup the IRQ
> vectors.

If you can please add this API with just a few users, and then convert
remaining users via the subsystem trees in the next cycle.
There's no need to risk wasting maintainer time on conflicts with
conversions like this.

Re: [PATCH 01/37] PCI/MSI: Add Devres managed IRQ vectors allocation

[Shawn Lin]

在 2026/02/24 星期二 8:04, Jakub Kicinski 写道:
> On Mon, 23 Feb 2026 23:29:40 +0800 Shawn Lin wrote:
>> pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for
>> pci device drivers which rely on the devres machinery to help cleanup the IRQ
>> vectors.
> 
> If you can please add this API with just a few users, and then convert
> remaining users via the subsystem trees in the next cycle.
> There's no need to risk wasting maintainer time on conflicts with
> conversions like this.

Thanks for the suggestion, Jakub. I have little experience with 
cross-subsystem cleanups like this, so your suggestion is very helpful.

> 

Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free

[Shawn Lin]

在 2026/02/24 星期二 1:38, Andy Shevchenko 写道:
> On Tue, Feb 24, 2026 at 12:09:37AM +0800, Shawn Lin wrote:
>> 在 2026/02/23 星期一 23:50, Andy Shevchenko 写道:
>>> On Mon, Feb 23, 2026 at 5:32 PM Shawn Lin <shawn.lin@rock-chips.com> wrote:
>>>>
>>>> This patch series addresses a long-standing design issue in the PCI/MSI
>>>> subsystem where the implicit, automatic management of IRQ vectors by
>>>> the devres framework conflicts with explicit driver cleanup, creating
>>>> ambiguity and potential resource management bugs.
>>>>
>>>> ==== The Problem: Implicit vs. Explicit Management ====
>>>> Historically, `pcim_enable_device()` not only manages standard PCI resources
>>>> (BARs) via devres but also implicitly triggers automatic IRQ vector management
>>>> by setting a flag that registers `pcim_msi_release()` as a cleanup action.
>>>>
>>>> This creates an ambiguous ownership model. Many drivers follow a pattern of:
>>>> 1. Calling `pci_alloc_irq_vectors()` to allocate interrupts.
>>>> 2. Also calling `pci_free_irq_vectors()` in their error paths or remove routines.
>>>>
>>>> When such a driver also uses `pcim_enable_device()`, the devres framework may
>>>> attempt to free the IRQ vectors a second time upon device release, leading to
>>>> a double-free. Analysis of the tree shows this hazardous pattern exists widely,
>>>> while 35 other drivers correctly rely solely on the implicit cleanup.
>>>
>>> Is this confirmed? What I read from the cover letter, this series was
>>> only compile-tested, so how can you prove the problem exists in the
>>> first place?
>>
>> Yes, it's confirmed. My debug of a double free issue of a out-of-tree
>> PCIe wifi driver which uses
>> pcim_enable_device + pci_alloc_irq_vectors + pci_free_irq_vectors expose
>> it. And we did have a TODO to cleanup this hybrid usage, targeted in
>> this cycle[1] suggested by Philipp:
> 
> Okay, fair enough. I think this bit was missing in the cover letter.
> 
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=msi
> 
>>>> ==== The Solution: Making Management Explicit ====
>>>> This series enforces a clear, predictable model:
>>>> 1.  New Managed API (Patch 1/37): Introduces pcim_alloc_irq_vectors() and
>>>>       pcim_alloc_irq_vectors_affinity(). Drivers that desire devres-managed IRQ
>>>>       vectors should use these functions, which set the is_msi_managed flag and
>>>>       ensure automatic cleanup.
>>>> 2.  Patches 2 through 36 convert each driver that uses pcim_enable_device() alongside
>>>>       pci_alloc_irq_vectors() and relies on devres for IRQ vector cleanup to instead
>>>>       make an explicit call to pcim_alloc_irq_vectors().
>>>> 3.  Core Change (Patch 37/37): With the former cleanup, now modifies pcim_setup_msi_release()
>>>>       to check only the is_msi_managed flag. This decouples automatic IRQ cleanup from
>>>>       pcim_enable_device(). IRQ vectors allocated via pci_alloc_irq_vectors*()
>>>>       are now solely the driver's responsibility to free with pci_free_irq_vectors().
>>>>
>>>> With these changes, we clear ownership model: Explicit resource management eliminates
>>>> ambiguity and follows the "principle of least surprise." New drivers choose one model and
>>>> be consistent.
>>>> - Use `pci_alloc_irq_vectors()` + `pci_free_irq_vectors()` for explicit control.
>>>> - Use `pcim_alloc_irq_vectors()` for devres-managed, automatic cleanup.
>>>
>>> Have you checked previous attempts? Why is your series better than those?
>>

Thanks for sharing this 5-years-old discusstion, I totally missed it.

I read the V7 discussion, and it seems to have disappeared without much
follow-up, like a stone dropped into the ocean. For five years, newly
added drivers have continued to misuse these APIs incorrectly, and
we’ve been watching it happen. I can’t really claim this patch series
is inherently better than Dejin’s earlier work at its core, this is
just about fixing one entire category of misuse in a single pass.

According to Bjorn's final search and reply, if we include the removal
of deprecated APIs, it would require a massive amount of work and might
span many release cycles. Unfortunately, the work never began, and the
cleanup might never be completed. I’m not sure if folks have changed
their minds now. Can we at least start by completing the changes for the
pci_alloc_irq_vectors category?


>> There seems not previous attempts.
> 
> Maybe we are looking to the different projects...
> 
> https://lore.kernel.org/all/?q=pcim_alloc_irq_vectors
> 
>>>> ==== Testing And Review ====
>>>> 1. This series is only compiled test with allmodconfig.
>>>> 2. Given the substantial size of this patch series, I have structured the mailing
>>>>      to facilitate efficient review. The cover letter, the first patch and the last one will be sent
>>>>      to all relevant mailing lists and key maintainers to ensure broad visibility and
>>>>      initial feedback on the overall approach. The remaining subsystem-specific patches
>>>>      will be sent only to the respective subsystem maintainers and their associated
>>>>      mailing lists, reducing noise.
> 

Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free

[Simon Richter]

Hi,

On 2/24/26 12:29 AM, Shawn Lin wrote:

> When such a driver also uses `pcim_enable_device()`, the devres framework may
> attempt to free the IRQ vectors a second time upon device release, leading to
> a double-free. Analysis of the tree shows this hazardous pattern exists widely,
> while 35 other drivers correctly rely solely on the implicit cleanup.

Would it make sense to have a function pcim_free_irq_vectors(), to allow 
explicit freeing even if the device is otherwise managed, analogous to 
pcim_iounmap()?

    Simon

Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free

[Philipp Stanner]

On Tue, 2026-02-24 at 13:14 +0900, Simon Richter wrote:
> Hi,
> 
> On 2/24/26 12:29 AM, Shawn Lin wrote:
> 
> > When such a driver also uses `pcim_enable_device()`, the devres framework may
> > attempt to free the IRQ vectors a second time upon device release, leading to
> > a double-free. Analysis of the tree shows this hazardous pattern exists widely,
> > while 35 other drivers correctly rely solely on the implicit cleanup.
> 
> Would it make sense to have a function pcim_free_irq_vectors(), to allow 
> explicit freeing even if the device is otherwise managed, analogous to 
> pcim_iounmap()?

We used to add those. In part because it is easier to port old users.

Nowadays I tend to think that those APIs were more on the too-complex
than too-simple side for a long time. As an expert or as the API
designer you wouldn't expect it, but there are actually far too many
users who came to believe they always have to use pcim_iounmap() and
counter parts.

If I could design it from scratch I would probably try to tell users to
use the unmanaged versions instead of revoking the devres consequence.

Devres is actually about your consequence always happening whenever the
driver unloads, for whatever reason.


P.

Re: [PATCH 01/37] PCI/MSI: Add Devres managed IRQ vectors allocation

[Philipp Stanner]

On Tue, 2026-02-24 at 10:08 +0800, Shawn Lin wrote:
> 在 2026/02/24 星期二 8:04, Jakub Kicinski 写道:
> > On Mon, 23 Feb 2026 23:29:40 +0800 Shawn Lin wrote:
> > > pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for
> > > pci device drivers which rely on the devres machinery to help cleanup the IRQ
> > > vectors.
> > 
> > If you can please add this API with just a few users, and then convert
> > remaining users via the subsystem trees in the next cycle.
> > There's no need to risk wasting maintainer time on conflicts with
> > conversions like this.
> 
> Thanks for the suggestion, Jakub. I have little experience with 
> cross-subsystem cleanups like this, so your suggestion is very helpful.


When I removed the hybrid nature of pci_request_region() et al., I
concluded that there were so few users that doing them all in one run
was sufficient.

For larger reworks, like removing pcim_iomap_table(), a slower step-by-
step strategy is necessary for the reasons that Jakub details.

It is then smart to omit an easy to port subsystem / driver for the
ultimate patch series where one then removes the hybrid behavior from
PCI itself, after porting the last driver.

In general,  as Jakub details, those step-by-step cleanups are a bit
safer, since you can proof valid behavior early on and in case of an
explosion they are very easy to revert.


P.

Re: [PATCH 01/37] PCI/MSI: Add Devres managed IRQ vectors allocation

[Shawn Lin]

在 2026/02/24 星期二 15:47, Philipp Stanner 写道:
> On Tue, 2026-02-24 at 10:08 +0800, Shawn Lin wrote:
>> 在 2026/02/24 星期二 8:04, Jakub Kicinski 写道:
>>> On Mon, 23 Feb 2026 23:29:40 +0800 Shawn Lin wrote:
>>>> pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for
>>>> pci device drivers which rely on the devres machinery to help cleanup the IRQ
>>>> vectors.
>>>
>>> If you can please add this API with just a few users, and then convert
>>> remaining users via the subsystem trees in the next cycle.
>>> There's no need to risk wasting maintainer time on conflicts with
>>> conversions like this.
>>
>> Thanks for the suggestion, Jakub. I have little experience with
>> cross-subsystem cleanups like this, so your suggestion is very helpful.
> 
> 
> When I removed the hybrid nature of pci_request_region() et al., I
> concluded that there were so few users that doing them all in one run
> was sufficient.
> 
> For larger reworks, like removing pcim_iomap_table(), a slower step-by-
> step strategy is necessary for the reasons that Jakub details.
> 
> It is then smart to omit an easy to port subsystem / driver for the
> ultimate patch series where one then removes the hybrid behavior from
> PCI itself, after porting the last driver.
> 
> In general,  as Jakub details, those step-by-step cleanups are a bit
> safer, since you can proof valid behavior early on and in case of an
> explosion they are very easy to revert.
> 

Thank you, Philipp. I wish I had attended your talk at FOSDEM 2025 on
removing pcim_iomap_table earlier. This first version was perhaps a bit 
too aggressive. For v2, I think the plan should start with addressing 
the switchtec and vmd drivers, since both of those, along with the new 
API additions, can be handled entirely within the PCI subsystem scope.

> 
> P.
> 

Re: [PATCH 01/37] PCI/MSI: Add Devres managed IRQ vectors allocation

[Philipp Stanner]

On Tue, 2026-02-24 at 16:21 +0800, Shawn Lin wrote:
> 在 2026/02/24 星期二 15:47, Philipp Stanner 写道:
> > On Tue, 2026-02-24 at 10:08 +0800, Shawn Lin wrote:
> > > 在 2026/02/24 星期二 8:04, Jakub Kicinski 写道:
> > > > On Mon, 23 Feb 2026 23:29:40 +0800 Shawn Lin wrote:
> > > > > pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for
> > > > > pci device drivers which rely on the devres machinery to help cleanup the IRQ
> > > > > vectors.
> > > > 
> > > > If you can please add this API with just a few users, and then convert
> > > > remaining users via the subsystem trees in the next cycle.
> > > > There's no need to risk wasting maintainer time on conflicts with
> > > > conversions like this.
> > > 
> > > Thanks for the suggestion, Jakub. I have little experience with
> > > cross-subsystem cleanups like this, so your suggestion is very helpful.
> > 
> > 
> > When I removed the hybrid nature of pci_request_region() et al., I
> > concluded that there were so few users that doing them all in one run
> > was sufficient.
> > 
> > For larger reworks, like removing pcim_iomap_table(), a slower step-by-
> > step strategy is necessary for the reasons that Jakub details.
> > 
> > It is then smart to omit an easy to port subsystem / driver for the
> > ultimate patch series where one then removes the hybrid behavior from
> > PCI itself, after porting the last driver.
> > 
> > In general,  as Jakub details, those step-by-step cleanups are a bit
> > safer, since you can proof valid behavior early on and in case of an
> > explosion they are very easy to revert.
> > 
> 
> Thank you, Philipp. I wish I had attended your talk at FOSDEM 2025 on
> removing pcim_iomap_table earlier. This first version was perhaps a bit 
> too aggressive.

No worries at all, it's very cool that you pick this work up!

>  For v2, I think the plan should start with addressing
> the switchtec and vmd drivers, since both of those, along with the new 
> API additions, can be handled entirely within the PCI subsystem scope.

Sounds reasonable to me.

Regards
Philipp

Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free

[Andy Shevchenko]

On Tue, Feb 24, 2026 at 08:39:43AM +0100, Philipp Stanner wrote:
> On Tue, 2026-02-24 at 13:14 +0900, Simon Richter wrote:
> > On 2/24/26 12:29 AM, Shawn Lin wrote:

> > > When such a driver also uses `pcim_enable_device()`, the devres framework may
> > > attempt to free the IRQ vectors a second time upon device release, leading to
> > > a double-free. Analysis of the tree shows this hazardous pattern exists widely,
> > > while 35 other drivers correctly rely solely on the implicit cleanup.
> > 
> > Would it make sense to have a function pcim_free_irq_vectors(), to allow 
> > explicit freeing even if the device is otherwise managed, analogous to 
> > pcim_iounmap()?
> 
> We used to add those. In part because it is easier to port old users.
> 
> Nowadays I tend to think that those APIs were more on the too-complex
> than too-simple side for a long time. As an expert or as the API
> designer you wouldn't expect it, but there are actually far too many
> users who came to believe they always have to use pcim_iounmap() and
> counter parts.
> 
> If I could design it from scratch I would probably try to tell users to
> use the unmanaged versions instead of revoking the devres consequence.

+many.

> Devres is actually about your consequence always happening whenever the
> driver unloads, for whatever reason.

I believe you meant "unbinds". The device<-->driver link can be broken
without unloading the driver.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free

[Philipp Stanner]

On Tue, 2026-02-24 at 11:12 +0200, Andy Shevchenko wrote:
> On Tue, Feb 24, 2026 at 08:39:43AM +0100, Philipp Stanner wrote:
> > On Tue, 2026-02-24 at 13:14 +0900, Simon Richter wrote:
> > > On 2/24/26 12:29 AM, Shawn Lin wrote:
> 
> > > > When such a driver also uses `pcim_enable_device()`, the devres framework may
> > > > attempt to free the IRQ vectors a second time upon device release, leading to
> > > > a double-free. Analysis of the tree shows this hazardous pattern exists widely,
> > > > while 35 other drivers correctly rely solely on the implicit cleanup.
> > > 
> > > Would it make sense to have a function pcim_free_irq_vectors(), to allow 
> > > explicit freeing even if the device is otherwise managed, analogous to 
> > > pcim_iounmap()?
> > 
> > We used to add those. In part because it is easier to port old users.
> > 
> > Nowadays I tend to think that those APIs were more on the too-complex
> > than too-simple side for a long time. As an expert or as the API
> > designer you wouldn't expect it, but there are actually far too many
> > users who came to believe they always have to use pcim_iounmap() and
> > counter parts.
> > 
> > If I could design it from scratch I would probably try to tell users to
> > use the unmanaged versions instead of revoking the devres consequence.
> 
> +many.

hm?

> 
> > Devres is actually about your consequence always happening whenever the
> > driver unloads, for whatever reason.
> 
> I believe you meant "unbinds". The device<-->driver link can be broken
> without unloading the driver.

Yes, thx for pointing that out. Greg KH AFAIK always calls it "driver
detach".

P.

Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free

[Andy Shevchenko]

On Tue, Feb 24, 2026 at 11:30:28AM +0100, Philipp Stanner wrote:
> On Tue, 2026-02-24 at 11:12 +0200, Andy Shevchenko wrote:
> > On Tue, Feb 24, 2026 at 08:39:43AM +0100, Philipp Stanner wrote:
> > > On Tue, 2026-02-24 at 13:14 +0900, Simon Richter wrote:

...

> > > If I could design it from scratch I would probably try to tell users to
> > > use the unmanaged versions instead of revoking the devres consequence.
> > 
> > +many.

> hm?

I'm supporting you with many hands up (more than I possess)!

> > > Devres is actually about your consequence always happening whenever the
> > > driver unloads, for whatever reason.
> > 
> > I believe you meant "unbinds". The device<-->driver link can be broken
> > without unloading the driver.
> 
> Yes, thx for pointing that out. Greg KH AFAIK always calls it "driver
> detach".

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 01/37] PCI/MSI: Add Devres managed IRQ vectors allocation

[Jonathan Cameron]

On Mon, 23 Feb 2026 23:29:40 +0800
Shawn Lin <shawn.lin@rock-chips.com> wrote:

> pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for
> pci device drivers which rely on the devres machinery to help cleanup the IRQ
> vectors.

It might be worth adding some details on why we need the is_msi_managed
flag in the first place vs just doing conventional devm_add_action_or_reset()
with pci_free_irq_vectors().