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

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

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