Re: [PATCH v3 10/10] selftests/liveupdate: Add a test for preserving tmpfs files

[Pratyush Yadav <pratyush@kernel.org>]

On Tue, Nov 03 2026, David Matlack wrote:

> Add luo_tmpfs, a kexec test for preserving tmpfs files and memfds, and
> for retrieving tmpfs files onto a tmpfs mount with struct
> liveupdate_shmem_retrieve_arg.
>
> Stage 1 preserves the source files of each test case. Stage 2 runs
> each test case in its own directory, with its own tmpfs mounts, so that
> block usage can be checked exactly with statfs() and st_blocks. The test
> cases cover:
>
>  - The restored file: contents, size, position, seals and holes, for
>    linked and unlinked source files.
>
>  - Creating the file: it is created like with open(O_TMPFILE), with the
>    requested mode minus the umask, owned by the caller, and not linked
>    until userspace links it, unless it asked for O_EXCL. Also O_RDONLY
>    and O_WRONLY files, other open() flags such as O_APPEND, O_NONBLOCK
>    and O_CLOEXEC, read-only mounts, and directories that the caller
>    can't write to.
>
>  - Preserving files that can't be written to: a binary while it is
>    executed, through a read-only fd, files on read-only mounts and
>    superblocks, and immutable files, including sparse ones, whose holes
>    are filled. Preserving someone else's file that the caller can't
>    write to fails, and so does preserving a file through a write-only
>    fd or an append-only file.
>
>  - Executing restored binaries: a restored binary can be executed
>    before the session is finished if it was retrieved with O_RDONLY, but
>    not if it was retrieved for writing, since LUO keeps the file open
>    until then. These test cases execute copies of the test binary.
>
>  - Block accounting: the file fits a mount of exactly its size, and a
>    large folio that extends past the end of the file is charged in full.
>    Running out of space, or hitting the memcg limit, fails permanently,
>    and leaves nothing charged to the mount or the memcg. The session can
>    still be finished.
>
>  - memfds: they are only retrieved as memfds, with their seals, and
>    files from tmpfs mounts only onto a tmpfs mount.
>
>  - Interactions with LUO: invalid arguments, which can be retried,
>    retrieving a token twice, and outgoing sessions.
>
> Also check that the size of a preserved file is frozen, and that the
> test doesn't trigger kernel warnings.
>
> Enable CONFIG_TRANSPARENT_HUGEPAGE for the large folio test cases,
> CONFIG_MEMCG for the memcg test case and CONFIG_TMPFS_XATTR for
> FS_IOC_SETFLAGS. Those test cases are skipped without them.
>
> tmpfs quotas are not tested, since the test runs as root, which is not
> subject to quota limits.
>
> Signed-off-by: David Matlack <dmatlack@google.com>
> ---
>  tools/testing/selftests/liveupdate/Makefile   |    1 +
>  tools/testing/selftests/liveupdate/config     |    4 +
>  .../testing/selftests/liveupdate/luo_tmpfs.c  | 2055 +++++++++++++++++

Umm, no way I am reading all this...

LLMs are great at generating tests, and I'm not saying there is no value
in this. It is just that this massive code dump is unreviewable by
humans. It is also unfair to the human reviewer because it took many
orders of magnitude less effort to _write_ them with an LLM.

What do you all reckon we should do about this? Trust the LLM to get the
testing right? Do we give up human maintenance of tests entirely? Do we
do fault injection to test the tests themselves?

Or do we make the tests smaller and more human reviewable?

>  .../selftests/liveupdate/run-vmtests.sh       |    1 +
>  4 files changed, 2061 insertions(+)
>  create mode 100644 tools/testing/selftests/liveupdate/luo_tmpfs.c
>
[...]

-- 
Regards,
Pratyush Yadav