Re: [PATCH RFC 12/17] KVM: selftests: Test guest_memfd with mounted tmpfs root directory

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] selftests/kvm: guest_memfd_test unconditionally aborts on non-THP kernels
- [Low] selftests/kvm: unhandled TEST_ASSERT failures leak host tmpfs mounts
--

commit 7820bbcbdad0955765992f96c9032de44d05bad4
Author: Ackerley Tng <ackerleytng@google.com>

KVM: selftests: Test guest_memfd with mounted tmpfs root directory

This commit adds test coverage to verify that opening the root directory
of an existing mounted tmpfs filesystem and passing its file descriptor
as the resource pool succeeds across guest_memfd subtests.

> diff --git a/tools/testing/selftests/kvm/guest_memfd_test.c b/tools/testing/selftests/kvm/guest_memfd_test.c
> index 73212d5307049..94ef64474f2a0 100644
> --- a/tools/testing/selftests/kvm/guest_memfd_test.c
> +++ b/tools/testing/selftests/kvm/guest_memfd_test.c
> @@ -541,66 +543,122 @@ static void test_resource_fd_tmpfs_huge(struct kvm_vm *vm)
>  	close(pool_fd);
>  }

[Severity: Medium]
Does test_resource_fd_tmpfs_huge() unconditionally abort on non-THP kernels?

It appears this test calls create_tmpfs_pool_fd("always", ...) which relies on
TEST_ASSERT() to verify the fsconfig system call. If the host kernel is built
without Transparent Hugepage support (CONFIG_TRANSPARENT_HUGEPAGE=n), tmpfs
will reject the "huge" mount option with EINVAL.

Since the assertion fails, does this fatally terminate the entire test suite
rather than gracefully skipping this specific THP test?

> -#define ____gmem_test(__test, __vm, __flags, __gmem_size, args...)		\
> +enum gmem_pool_type {
> +	GMEM_POOL_NONE,
> +	GMEM_POOL_FSMOUNT,
> +	GMEM_POOL_MOUNTED_DIR,
> +};
> +
> +struct gmem_pool {
> +	int fd;
> +	char path[PATH_MAX];
> +	bool is_mounted;
> +};
> +
> +static struct gmem_pool create_gmem_pool(size_t size, enum gmem_pool_type type)
> +{
[ ... ]
> +	strcpy(pool.path, "/tmp/gmem_test_dir_XXXXXX");
> +	TEST_ASSERT(mkdtemp(pool.path), "mkdtemp failed");
> +
> +	if (syscall(__NR_move_mount, mnt_fd, "", AT_FDCWD, pool.path,
> +		    MOVE_MOUNT_F_EMPTY_PATH)) {
> +		close(mnt_fd);
> +		rmdir(pool.path);
> +		TEST_REQUIRE(false);
> +	}
> +	close(mnt_fd);
> +
> +	pool.fd = open(pool.path, O_RDONLY | O_DIRECTORY);
> +	TEST_ASSERT(pool.fd >= 0, "open mounted tmpfs root failed");
> +	pool.is_mounted = true;
> +
> +	return pool;
> +}
[ ... ]
> +#define ____gmem_test(__test, __vm, __flags, __pool_type, __gmem_size, args...)	\
>  do {										\
> -	int pool_fd = -1;							\
> +	struct gmem_pool pool = { .fd = -1 };					\
>  	int fd;									\
>  										\
>  	if ((__flags) & GUEST_MEMFD_FLAG_USE_RESOURCE) {			\
> -		pool_fd = create_tmpfs_pool_fd("never", true, __gmem_size);	\
> +		pool = create_gmem_pool(__gmem_size, __pool_type);		\
>  		fd = vm_create_guest_memfd_resource(__vm, __gmem_size,		\
> -						    __flags, pool_fd);		\
> +						    __flags, pool.fd);		\
>  	} else {								\
>  		fd = vm_create_guest_memfd(__vm, __gmem_size, __flags);	\
>  	}									\
>  										\
>  	test_##__test(args);							\
>  	close(fd);								\
> -	if (pool_fd >= 0)							\
> -		close(pool_fd);							\
> +	destroy_gmem_pool(&pool);						\
>  } while (0)

[Severity: Low]
Can TEST_ASSERT failures in the test macros leak host tmpfs mounts?

In create_gmem_pool(), the tmpfs mount is attached to a persistent host path
in the host's temporary directory when using GMEM_POOL_MOUNTED_DIR. This is
done without unsharing the mount namespace.

If test_##__test() triggers a TEST_ASSERT failure, process execution will
terminate immediately. This bypasses the call to destroy_gmem_pool(), leaving
persistent mount points in the host environment. Repeated test failures could
pollute the host environment and consume system resources over time.

Is there a way to unshare the mount namespace or register a cleanup handler
so that abrupt test terminations don't leak mounts on the host?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260925-gmem-tmpfs-backend-v1-0-d36159822d18@google.com?part=12