Re: [RFC PATCH 0/5] liveupdate: LIVEUPDATE_SESSION_RETRIEVE_INTO_FD

[Pratyush Yadav <pratyush@kernel.org>]

Hi,

On Tue, Sep 01 2026, David Matlack wrote:

> This series adds support for LIVEUPDATE_SESSION_RETRIEVE_INTO_FD, a new
> UAPI to enable preserved files to be restored into a userspace-provided
> file instead of a kernel-allocated file, and uses this to support
> preserving tmpfs files in-place without any changes to the LUO ABI.
>
> The Live Update Orchestrator (LUO) API currently explicitly returns a
> new struct file for every preserved file during retrieve() (e.g. via
> memfd_alloc_file()). This then forces userspace to use anonymous memfds
> for all in-memory files it wants to preserve. This works reasonably well
> for VM guest memory but does not work well for other types of files that
> userspace may want to preserve (e.g. in-memory logs, binaries,
> configuration files, etc.).
>
> Preserving entire tmpfs mounts in-place would require a large amount of
> kernel support and would effectively make tmpfs an ABI, which is a
> non-starter (or so I hear). Instead, we can delegate the reconstruction
> of the tmpfs mounts (directory structure, permissions, etc.) post-kexec
> to userspace. The kernel just needs to preserve the contents of tmpfs
> files and provide userspace a mechanism to restore those contents back
> into a specific file on the filesystem after the kexec. Hence,
> LIVEUPDATE_SESSION_RETRIEVE_INTO_FD.

Based on the discussion at LPC, we came to the conclusion that this is
the path forward.

Before reviewing the code, here's an idea that Pasha briefly brought up
briefly at LPC, and I more or less agree. I'd like other opinions on
this.

Should we make the interface more generic by allowing userspace to pass
extra arguments to PRESERVE_FD and RETRIEVE_FD? This effectively gives
each file handler an additional uAPI of its own. The upside is that it
would be more extensible and we should be able to accommodate more use
cases with this. The memfd/shmem extra uAPI will take an optional target
file to retrieve into.

For example, the guest_memfd patches might use this to tell the KVM FD
to retrieve the guest_memfd into. Of course, KVM needs to see if this
makes sense (alternative being preserving the KVM FD too), but this is
just an example of how it might be used. I think VFIO also does some
workarounds by using an anon inode on retrieve. It perhaps might be
useful there too, though I don't understand that problem well enough to
talk in more detail.

>
> An alternative approach to restoring data to a named file would be
> supporting a zero-copy sendfile() that can be used to convert named
> tmpfs files to/from memfds across the kexec. But this poses significant
> challenges on the *preserve* side since the preserved file might still
> be actively in use. The benefit of the retrieve-into approach introduced
> in this series is that it does not require dealing with two different
> files. There is only ever one file that owns the preserved memory.
>
> By leaving file and metadata allocation purely in the purview of
> userspace, programs can create the target files where they want, with
> the names and security permissions they desire, before directing the
> kernel to restore the preserved folios into them.
>
> Currently, only tmpfs shmem files are allowed as valid target receptors.
> Attempting to target populated files, or anything other than an empty
> shmem file, will trigger -EINVAL. HugeTLBfs files could be supported in
> the future.

I suppose we should rename all the memfd_luo_* stuff to shmem_luo_*?

>
> The coding work for this series was done with assistance from Gemini. I
> am not sure what is the latest recommendation is with respect to adding
> Assisted-by tags, but I can add them when I send out the real patches if
> this RFC looks acceptable.

The latest guidelines per Documentation/process/coding-assistants.rst
seem to be "Assisted-by: LLM".

Although in _my_ opinion, I'd reckon most patches these days are
assisted by an LLM. The code might not necessarily be generated by an
LLM, but I think a large majority of developers use LLMs in some
capacity during patch development. So "Assisted-by: LLM" doesn't add any
value to me. Other people seem to find it useful, so please do feel free
to add it to your patches.

[...]

-- 
Regards,
Pratyush Yadav