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

[Philipp Stanner]

On Tue, 2026-02-24 at 11:12 +0200, Andy Shevchenko wrote:
> 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.

hm?

> 
> > 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.

Yes, thx for pointing that out. Greg KH AFAIK always calls it "driver
detach".

P.