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.
