Re: [PATCH v2 01/16] liveupdate: luo_file: Add internal APIs for file preservation

[Samiullah Khawaja]

On Fri, May 29, 2026 at 04:12:20PM +0000, Ankit Soni wrote:
> On Mon, May 18, 2026 at 07:08:01PM +0000, Samiullah Khawaja wrote:
> > On Mon, May 18, 2026 at 11:40:58AM +0000, Pranjal Shrivastava wrote:
> > > On Mon, Apr 27, 2026 at 05:56:18PM +0000, Samiullah Khawaja wrote:
> > > > From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
> > > >
> > > > The core liveupdate mechanism allows userspace to preserve file
> > > > descriptors. However, kernel subsystems often manage struct file
> > > > objects directly and need to participate in the preservation process
> > > > programmatically without relying solely on userspace interaction.
> > > >
> > > > Signed-off-by: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
> > > > Signed-off-by: Samiullah Khawaja <skhawaja@xxxxxxxxxx>
> > >
>
> [..]
>
> > > > + *
> > > > + * Context: It must be called with session mutex acquired of a restored session.
> > > > + * Return: 0 on success. Returns -ENOENT if no file with the matching token is
> > > > + *         found, or any other negative errno on failure.
> > > > + */
> > > > +int liveupdate_get_file_incoming(struct liveupdate_session *s, u64 token,
> > > > +				 struct file **filep)
> > > > +{
> > > > +	return luo_retrieve_file(luo_file_set_from_session_locked(s),
> > > > +				 token, filep);
> > > > +}
> > >
> > > Nit: Shouldn't we export both of these functions via EXPORT_SYMBOL_GPL?
> > > Since, these new APIs are intended for kernel subsystems to participate
> > > programmatically, there could be IOMMU drivers (or others) that can be
> > > compiled as loadable modules. Thus we should export these APIs via
> > > EXPORT_SYMBOL_GPL(). If they aren't exported, any loadable module
> > > attempting to use them will compile successfully (due to the header), but
> > > will fail to load at runtime with an Unknown symbol error.
> > >
> > > IIUC, if a function isn't exported with EXPORT_SYMBOL, it remains hidden
> > > inside vmlinux, (i.e. it isn't in the kernel's global symbol table used
> > > during modprobe).
> >
> > Agreed. Will Update this.
> >
> > I think there are other LUO APIs that are not exported and can be used
> > by modules. Let me check those also.
>
> Hi,
> +1 to Pranjal's EXPORT_SYMBOL_GPL nit, and I'd like to extend it.
> With CONFIG_IOMMUFD=m && CONFIG_IOMMU_LIVEUPDATE=y
> the series fails at modpost, not at modprobe — kernel won't even build:
>
>  ERROR: modpost: "memfd_get_seals" [iommufd.ko] undefined!
>  ERROR: modpost: "iommu_preserve_device" [iommufd.ko] undefined!
>  ERROR: modpost: "iommu_unpreserve_device" [iommufd.ko] undefined!
>  ERROR: modpost: "liveupdate_register_file_handler" [iommufd.ko] undefined!
>  ERROR: modpost: "liveupdate_get_token_outgoing" [iommufd.ko] undefined!
>  ERROR: modpost: "iommufd_liveupdate_register" [iommufd.ko] undefined!
>  ERROR: modpost: "iommufd_liveupdate_unregister" [iommufd.ko] undefined!
>  ERROR: modpost: "iommufd_hwpt_liveupdate_mark_preserve" [iommufd.ko] undefined!
>
> Two issues:
> 1) drivers/iommu/iommufd/Makefile (patch 12) builds liveupdate.o into vmlinux
>   instead of iommufd.ko — needs to be a composite member, not a top-level obj:
>     -obj-$(CONFIG_IOMMU_LIVEUPDATE) += liveupdate.o
>     +iommufd-$(CONFIG_IOMMU_LIVEUPDATE) += liveupdate.o

Thanks for this, I will update and test this.
>   This fixes the iommufd_liveupdate_{register,unregister} and
>   iommufd_hwpt_liveupdate_mark_preserve errors above.
>
>
> 2) Beyond the two LUO functions Pranjal mentioned, four more vmlinux symbols
>   need EXPORT_SYMBOL_GPL.

Yes, we will have a commit for those in the VFIO series as it also uses
those LUO symbols, and this series has a dependency on VFIO series.
Please see the following commit from David:

https://lore.kernel.org/kvm/20260323235817.1960573-2-dmatlack@xxxxxxxxxx/
> Thanks,
> Ankit
>
> > >
> > > Thanks,
> > > Praan
> > >
> > > [1] https://elixir.bootlin.com/linux/v7.0-rc3/source/kernel/liveupdate/luo_file.c#L560
> > >