On Mon, Aug 25, 2025 at 01:56:55PM +0300, Andy Shevchenko wrote: > On Sat, Aug 23, 2025 at 04:32:22PM +0800, Zhang Heng wrote: > > The original sequence kfree(dd); pci_set_drvdata(pdev, NULL); creates a > > theoretical race condition window. Between these two calls, the pci_dev > > structure retains a dangling pointer to the already-freed device private > > data (dd). Any concurrent access to the drvdata (e.g., from an interrupt > > handler or an unexpected call to remove) would lead to a use-after-free > > kernel oops. > > > > Changes made: > > 1. `pci_set_drvdata(pdev, NULL);` - First, atomically sever the link > > from the pci_dev. > > 2. `kfree(dd);` - Then, safely free the private memory. > > > > This ensures the kernel state is always consistent before resources > > are released, adhering to defensive programming principles. ... > > iomap_err: > > - kfree(dd); > > pci_set_drvdata(pdev, NULL); > > - return rv; > > + kfree(dd); > > These two seems to me unrelated. How do you possible have a race? What's racy > there? (Yes, I have read the commit message, but I fail to see how it may lead > to anything here. My question in one of the previous patches was about needless > pci_set_drvdata() call. Do we even need that one? > > > done: > > return rv; Also note, 99.99% of the drivers do that cleanup in the driver core whenever it considers the best to do a such. So if you see an issue in this driver, the commit message should really explain much more. -- With Best Regards, Andy Shevchenko
