Re: [PATCH v7 03/12] PCI: liveupdate: Track incoming preserved PCI devices

On Mon, Jul 20, 2026 at 3:00 PM David Matlack <[email protected]> wrote:
>
> On Fri, Jul 17, 2026 at 3:38 PM Alex Williamson <[email protected]> wrote:
> >
> > On Fri, 10 Jul 2026 21:26:06 +0000
> > David Matlack <[email protected]> wrote:
> >
> > > @@ -298,6 +377,87 @@ void pci_liveupdate_unpreserve(struct pci_dev *dev)
> > >  }
> > >  EXPORT_SYMBOL_GPL(pci_liveupdate_unpreserve);
> > >
> > > +static struct pci_flb_incoming *pci_liveupdate_flb_get_incoming(void)
> > > +{
> > > +     struct pci_flb_incoming *incoming = NULL;
> > > +     int ret;
> > > +
> > > +     ret = liveupdate_flb_get_incoming(&pci_liveupdate_flb, (void **)&incoming);
> > > +
> > > +     /* Live Update is not enabled. */
> > > +     if (ret == -EOPNOTSUPP)
> > > +             return NULL;
> > > +
> > > +     /* Live Update is enabled, but there is no incoming FLB data. */
> > > +     if (ret == -ENODATA)
> > > +             return NULL;
> > > +
> > > +     /*
> > > +      * Live Update is enabled and there is incoming FLB data, but none of it
> > > +      * matches pci_liveupdate_flb.compatible.
> > > +      *
> > > +      * This could mean that no PCI FLB data was passed by the previous
> > > +      * kernel, but it could also mean the previous kernel used a different
> > > +      * compatibility string (i.e. a different ABI).
> > > +      */
> > > +     if (ret == -ENOENT) {
> > > +             pr_info_once("No incoming FLB matched %s\n", pci_liveupdate_flb.compatible);
> > > +             return NULL;
> > > +     }
> > > +
> > > +     /*
> > > +      * There is incoming FLB data that matches pci_liveupdate_flb.compatible
> > > +      * but it cannot be retrieved.
> > > +      */
> > > +     if (ret)
> > > +             panic("Failed to retrieve incoming FLB data (%d)\n", ret);
> > > +
> > > +     return incoming;
> > > +}
> >
> > I'm having trouble following the error escalation here.  What's
> > fundamentally the difference between FLB data being provided and not
> > compatible (subtle log message) versus FLB data being provided and
> > compatible but we cannot access it (panic!)?
>
> There is no fundamental difference IMO and I think we should handle
> them the same way (panic). The problem is the PCI core cannot actually
> distinguish between "PCI FLB provided and not compatible" (should
> panic) and "no PCI FLB provided" (should log). I would like to propose
> changes to LUO so that the FLB handlers can detect the former
> situation but that requires some non-trivial work that I didn't want
> to block on.
>
> For now, I guess you could say it is up to the user to not perform
> Live Update between incompatible versions. I can update the
> documentation.

An alternative approach would be to make the PCI compatibility string
just "pci" and then put the version number as the first field in
struct pci_ser. That would ensure the PCI core can always fetch its
FLB data and panic on a version mismatch. I think first-class handling
in LUO would be better, but that is a larger problem to solve; it also
needs to be solved for file handlers.

Pasha and Sami, what do you think?

> >
> > Don't both suggest devices are running but we can't get their FLB data
> > to continue letting them run?
> >
> > The errno interpretation is also slightly different than the comment
> > above liveupdate_flb_get_incoming():
> >
> >  * Return: 0 on success, or a negative errno on failure. -ENODATA means no
> >  * incoming FLB data, -ENOENT means specific flb not found in the incoming
> >  * data, -ENODEV if the FLB's module is unloading, and -EOPNOTSUPP when
> >  * live update is disabled or not configured.
>
> I think the only disagreement is the lack of specific -ENODEV
> handling. Is that what you are referring to?
>
> >
> > Thanks,
> > Alex