Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free
Andy Shevchenko <[email protected]> Mon, 23 Feb 2026 17:50:59 +0200
| Newsgroups | dev.linux.lists.mhi,dev.linux.lists.iommu,org.freedesktop.lists.dri-devel,org.infradead.lists.linux-i3c,org.infradead.lists.linux-riscv,org.kernel.vger.dmaengine,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-crypto,org.kernel.vger.linux-cxl,org.kernel.vger.linux-gpio,org.kernel.vger.linux-i2c,org.kernel.vger.linux-input,org.kernel.vger.linux-media,org.kernel.vger.linux-mmc,org.kernel.vger.linux-pci,org.kernel.vger.linux-serial,org.kernel.vger.linux-spi,org.kernel.vger.linux-usb,org.kernel.vger.netdev,org.kernel.vger.platform-driver-x86 |
|---|---|
| Message-ID | <CAHp75VeWD5A0r7-Uayyte1ZXXxdhLixd+z_y0xNeki0N+Ro=jQ@mail.gmail.com> |
On Mon, Feb 23, 2026 at 5:32 PM Shawn Lin <[email protected]> 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