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

[tarunsahu@google.com]

Pratyush Yadav <pratyush@kernel.org> writes:

> 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.

I agree, While developing the guest_memfd preservation support, I also
felt the need of upgrading the preservation and retrieval ioctl to have
arguments which will make it flexible. And help decouple the VM
preservation and guest_memfd preservation. I would love to see where
this argument idea goes.

~Tarun
>
>>
>> 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