Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free
Andy Shevchenko <[email protected]> Tue, 24 Feb 2026 11:12:15 +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 |
|---|---|
| Organization | Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo |
| Message-ID | <[email protected]> |
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