On Sat, 2025-08-23 at 16:32 +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.

I tend to disagree I think . This is the driver's probe() function. It
is always invoked serially by the driver core.

remove() cannot be called while probe() is still running.

Thus, the only potential explosion that could happen would be if an
interrupt handler were to be set up in this probe() and then accesses
dd.

However, if that were the case, everything would be exploding already
because there is no place in the code that tears down that interrupt
handler or other potential parallel accessors before kfree(dd) is
called.

In this case, the relevant call is pci_enable_msi(). Sooner errors,
like iomap_err: are jumped to before that's the case. Which is the only
sane design for probe() anyways. Otherwise, pci_disable_msi() switches
that off again; IOW: there are no racers.

So I think that the pci_set_drvdata(… NULL) can be removed
alltogether. 

When working on the probe() / remove() paths last and this year, I came
to believe that calls like that were often used because of a
misunderstanding of how the driver core APIs work.


P.