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: Philipp Stanner <hidden>
Date: 2026-02-24 07:40:28
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, 2026-02-24 at 13:14 +0900, Simon Richter wrote:
Hi,

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

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


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