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

[Samiullah Khawaja <skhawaja@google.com>]

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@soleen.com>
>> > >
>> > > 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@soleen.com>
>> > > Signed-off-by: Samiullah Khawaja <skhawaja@google.com>
>> >
>
>[..]
>
>> > > + *
>> > > + * 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@google.com/
>
>Thanks,
>Ankit
>
>> >
>> > Thanks,
>> > Praan
>> >
>> > [1] https://elixir.bootlin.com/linux/v7.0-rc3/source/kernel/liveupdate/luo_file.c#L560
>> >