Pratyush Yadav <[email protected]> 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
