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:

quoted

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.

...

quoted

 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?

quoted

 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