Re: [PATCH v2] block: mtip32xx: Prioritize state cleanup over memory freeing in the mtip_pci_probe error path.

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

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