Thread (22 messages) 22 messages, 7 authors, 2026-02-24

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

From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: 2026-02-24 09:12:36
Also in: dmaengine, dri-devel, linux-arm-msm, linux-crypto, linux-cxl, linux-gpio, linux-i2c, linux-i3c, linux-input, linux-iommu, linux-media, linux-mmc, linux-pci, linux-riscv, linux-serial, linux-spi, linux-usb, platform-driver-x86

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:
quoted
On 2/24/26 12:29 AM, Shawn Lin wrote:
quoted
quoted
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

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help