Re: [RESEND PATCH v3 0/3] Add Devres managed IRQ vectors allocation

Philipp Stanner
2026-04-22T07:11:19Z

Hi,

I did receive your first send-out of this v3. In case of doubt it's
possible to check on lore.kernel.org whether it was actually sent out.

On Wed, 2026-04-22 at 10:38 +0800, Shawn Lin wrote:
>
> There is 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.
>
> Historically, pcim_enable_device() not only manages standard PCI resources
> (BARs) via devres
>

JFYI, it doesn't do that anymore, since I fully removed that.

What is left though is the weird "plural functions",
pcim_iomap_regions().

I've done some work to also remove them, but it's a lot of work, and
especially the ATA subsystem is relatively difficult to port.

> but also implicitly triggers automatic IRQ vector management
> when calling pci_alloc_irq_vectors[_affinity], because pcim_enable_device()
> sets is_managed flag, thus pcim_msi_release() will register 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.

Also just as an idea: for your removal strategy it's probably a good
idea to carry a list of the problematic drivers along, if that's not
too much work. Once created, you could continuously update it on your
machine, to keep track and later to provide evidence when you finally
remove the API. That "35 other drivers" do it *correctly* isn't really
that useful to know; what's important is to know who might explode.

I did it this way:
https://lore.kernel.org/linux-pci/20250519112959.25487-2-phasta@kernel.org/

That then helps the maintainer to fearlessly merge your final removal,
building trust that the drivers are safe.

>
> This series introduces new managed APIs: pcim_alloc_irq_vectors()and
> pcim_alloc_irq_vectors_affinity(). Drivers that wish to have devres-managed IRQ
> vectors should use these functions. They are currently the same as non-devres
> managed version. In the short term, the series converts two drivers within the
> PCI subsystem to use the new APIs. The long-term goal is to convert all other
> drivers which wish to use these managed functions, and finally to remove the
> problematic hybrid management pattern from pcim_enable_device() and
> pcim_setup_msi_release() entirely.

10/10

P.

>
>
> Changes in v3:
> - Rework the commit message and function doc (Philipp)
> - Remove setting is_msi_managed flag from new APIs (Philipp)
>
> Changes in v2:
> - Rebase
> - Introduce patches only for PCI subsystem to convert the API
>
> Shawn Lin (3):
>   PCI/MSI: Add Devres managed IRQ vectors allocation
>   PCI: switchtec: Replace pci_alloc_irq_vectors() with
>     pcim_alloc_irq_vectors()
>   PCI: vmd: Replace pci_alloc_irq_vectors() with
>     pcim_alloc_irq_vectors()
>
>  drivers/pci/controller/vmd.c   |  4 ++--
>  drivers/pci/msi/api.c          | 47 ++++++++++++++++++++++++++++++++++++++++++
>  drivers/pci/switch/switchtec.c |  6 +++---
>  include/linux/pci.h            | 22 ++++++++++++++++++++
>  4 files changed, 74 insertions(+), 5 deletions(-)
>