From: "Pratyush Yadav (Google)" <pratyush@kernel.org>

Hi,

I brought this idea up in this week's Hypervisor Live Update bi-weekly.
I decided to try using an LLM to see if it can produce a
proof-of-concept quickly. This series is the end result.

The main use case is preserving in-memory files that have a filesystem
path. We already support memfd preservation, but memfds can't be linked
to a (user-visible) filesystem. This is needed for storing VMM packages
for live update on hosts that don't have a disk. A cold boot fetches the
binaries from network, but that is too slow for a live update.

David tried to solve the problem by introducing
LIVEUPDATE_SESSION_RETRIEVE_INTO_FD [0], which lets you provide a FD for
LUO to retrieve into. This is an alternative to the idea. It uses the
standard preservation and retrieval API that LUO already provides.

The core idea is to allow userspace to preserve a tmpfs mount FD. Once
the mount is preserved, userspace can pass in regular files in that
mount for preservation. The files take a dependency on the mount token,
and that is used for retrieving the files in the right mount. This saves
us from doing a full FS preservation and makes preservation of each file
explicit.

Currently only files in the root are supported. Files in subdirectories
will be rejected. This is mainly for simplicity. Complex mount features
like memory policies, id mappings, or casefolding are also not
supported. All these can be reconfigured after retrieve if really
needed.

The code re-uses a lot of the preservation and retrieval logic from
memfd preservation. It only adds some extra file and mount metadata on
top.

As I mentioned earlier, this is heavily LLM generated. The code is not
very polished and has some rough edges. That said, I have read all the
code and did significant cleanups of the LLM output. This includes
turning the 1600 or so lines it generated to a more modest 977 lines.
So (I think) it isn't complete AI garbage. And I think it does get the
core idea across.

The big exception to this is the changes to and use of VFS APIs. I am
not competent with VFS at all so I have mostly taken the LLM at its word
and haven't done my homework to see if the usage even makes sense.
That's why I have not Cced any of the VFS maintainers. I'd rather spare
them the pain.

[0] https://lore.kernel.org/kexec/20260901180713.4185641-1-dmatlack@google.com/T/#u

Regards,
Pratyush Yadav

Pratyush Yadav (Google) (6):
  liveupdate: luo_file: look up outgoing tokens by id
  shmem: add tmpfs_create_mount() to create tmpfs mounts internally
  fs/namespace: Add vfs_open_detached_mount()
  mm/memfd_luo: allow preserving a tmpfs mount
  mm/memfd_luo: allow preserving a tmpfs file
  selftests/liveupdate: add tmpfs kexec test

 Documentation/core-api/liveupdate.rst         |   1 +
 Documentation/mm/index.rst                    |   1 +
 Documentation/mm/tmpfs_preservation.rst       |  24 +
 MAINTAINERS                                   |   1 +
 fs/namespace.c                                |  59 ++
 include/linux/kho/abi/tmpfs.h                 |  83 +++
 include/linux/liveupdate.h                    |   6 +-
 include/linux/mount.h                         |   1 +
 include/linux/shmem_fs.h                      |   5 +
 kernel/liveupdate/luo_file.c                  |  21 +-
 mm/internal.h                                 |   1 +
 mm/memfd_luo.c                                | 558 +++++++++++++++++-
 mm/shmem.c                                    |  43 +-
 tools/testing/selftests/liveupdate/Makefile   |   1 +
 .../selftests/liveupdate/luo_kexec_tmpfs.c    | 191 ++++++
 .../selftests/liveupdate/run-vmtests.sh       |   1 +
 16 files changed, 977 insertions(+), 20 deletions(-)
 create mode 100644 Documentation/mm/tmpfs_preservation.rst
 create mode 100644 include/linux/kho/abi/tmpfs.h
 create mode 100644 tools/testing/selftests/liveupdate/luo_kexec_tmpfs.c


base-commit: db3db4c33a1cf89a201ad1a11c63f503b248ee32
-- 
2.56.0.rc1.310.g51773c2048-goog