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
