[PATCH v10 03/13] PCI: liveupdate: Track incoming preserved PCI devices

[David Matlack]

On 2026-10-13 04:40 PM, sashiko-bot at kernel.org wrote:
> > +    if (READ_ONCE(dev->liveupdate.incoming))
> > +        pci_WARN(dev, 1, "Destroying incoming-preserved device!\n");
>
> [Severity: High]
> Does this code risk silent memory corruption by only warning instead of
> panicking?
>
> When an incoming preserved device is destroyed, it is dropped from the
> kernel's resource tracking. However, the device may still be live and
> performing DMA if it was handed over by the previous kernel.

The device is not dropped from tracking. Its struct pci_dev_ser stays
in the incoming FLB with a non-zero refcount, so if the device is
enumerated again it is treated as incoming-preserved again, and if it
never finishes, pci_check_all_devices_finished() still catches it. Bus
numbers also cannot be reassigned, since the preserved upstream bridges
keep theirs.

As for MMIO resources such as BAR locations, they are not preserved
today. That will be handled in a future series.

> > +        pci_liveupdate_cleanup_device(dev);
>
> [Severity: High]
> Can an incoming preserved device that fails enumeration here cause a resource
> conflict?

A preserved device coming back with an unknown header type means the
hardware is probably broken. The PCI core cannot manage the device
either way, its state stays in the incoming FLB, and its upstream
bridges keep their bus numbers. I don't think it's necessary to panick
the entire host in this scenario.