Re: [PATCH v1 0/7] liveupdate: tmpfs preservation and early freeze

[David Matlack <dmatlack@google.com>]

On 2026-10-15 04:38 PM, Pasha Tatashin wrote:

> What if instead of retrieve-into an existing file FD, userspace passes
> a dir_fd on the target tmpfs mount where the file should be restored?

This is good. This eliminates the pinning race and also eliminates the
checks v1 had to do on the userspace-provided file.

> During preserve we can record the file's basename if the file was linked
> (or mark that it was unlinked). On retrieve, creates a brand-new file in
> dir_fd (e.g. starts as an unlinked O_TMPFILE on that tmpfs superblock),
> populates all the folios and metadata while the file is still unreachable
> by anyone else, links it into dir_fd under the preserved name at the end
> (or leaves it unlinked if the original file was unlinked), and returns
> the FD of the new file to userspace.

I don't think the name should be in the ABI though:

 - Userspace already has to know what each token is, so it knows the
   name. And a basename isn't enough anyway, since userspace still has
   to supply the directory.

 - "The name" isn't well defined. A file can have several hard links,
   and it can be renamed or unlinked between preserve and freeze.

 - Linking in the kernel needs a policy for collisions, and linking at
   finish() can fail (or find the name taken) at a point where there's
   no good way to report it.

 - The name isn't the only thing needed to create the file properly.
   There's also the mode, the owner (fsuid/fsgid, setgid directories,
   idmapped mounts), default ACLs and LSM labels, the access mode of the
   fd, and whether the file may be linked at all. If we record those in
   the ABI it grows a lot.

What if we model the retrieve args on open() directly? RETRIEVE_FD
behaves like openat(dirfd, ".", O_TMPFILE | flags, mode), then fills the
file, then returns the fd:

  struct liveupdate_memfd_retrieve_arg {
  	__u32		size;
  	__s32		dirfd;
  	__aligned_u64	flags;	/* subset of O_*, ORed with O_TMPFILE */
  	__aligned_u64	mode;
  };

In the kernel this is file_open_root(&dir_path, ".", O_TMPFILE | flags,
mode), which goes through the same path as open().

Userspace links the file into place with linkat() whenever it wants, the
usual O_TMPFILE way, or passes O_EXCL to make it unlinkable. Then
there's no name in the ABI or the uAPI, no linking in the kernel,
unlinked files are just files userspace never links, and "don't link it
until it's fully populated" comes for free.

One quirk: open() rejects O_TMPFILE without write access.  With LUO
holding the file until finish, that brings back the -ETXTBSY problem for
restored binaries. vfs_tmpfile() itself doesn't need write access, and
neither does filling the file, so I think we can allow an O_RDONLY |
O_TMPFILE here.

> I would like file type to stay exactly the same, I really don't want to 
> play the game where LUO can magically change file from one type to 
> another even if from Linux internal implementation they share a lot of 
> code, they are still a different file types from the user perspective.

Ok, I don't feel that strongly. We should just do it based on the
superblock rather than i_nlink, so that O_TMPFILE and unlinked tmpfs
files stay on a user mount.