Re: [PATCH v7 03/12] PCI: liveupdate: Track incoming preserved PCI devices
David Matlack <[email protected]> Mon, 20 Jul 2026 15:00:21 -0700
| Newsgroups | org.infradead.lists.kexec,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pci,org.kvack.linux-mm |
|---|---|
| Message-ID | <CALzav=eQ-0rbxh6Eekbt4zUoNGNZc_THmSCvVWVwE3om1BPtdw@mail.gmail.com> |
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. > > 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