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 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;

-- 
With Best Regards,
Andy Shevchenko