From: sashiko-bot@kernel.org
To: "Ackerley Tng" <ackerleytng@google.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH RFC 11/17] KVM: selftests: Test guest_memfd with anonymous fsmount() tmpfs pool
Date: Sat, 26 Sep 2026 01:02:35 +0000 [thread overview]
Message-ID: <20260926010236.054251F0089A@smtp.kernel.org> (raw)
In-Reply-To: <20260925-gmem-tmpfs-backend-v1-11-d36159822d18@google.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] kselftests: kvm: incorrect fd validation in create_tmpfs_pool_fd()
- [Medium] kselftests: kvm: brittle invalid size test implicitly uses resource_fd=0
- [Medium] kselftests: kvm: test fails on older kernels due to missing flag cap check
--
commit b9ccbfbf6c1bd14da922a66c6dd6f5735cd34ba0
Author: Ackerley Tng <ackerleytng@google.com>
KVM: selftests: Test guest_memfd with anonymous fsmount() tmpfs pool
Add test coverage verifying that creating a guest_memfd backed by an
anonymous tmpfs mount descriptor returned by fsmount() succeeds and
reports the requested file size.
> diff --git a/tools/testing/selftests/kvm/guest_memfd_test.c b/tools/testing/selftests/kvm/guest_memfd_test.c
> index e8199ed17b0f8..73212d5307049 100644
> --- a/tools/testing/selftests/kvm/guest_memfd_test.c
> +++ b/tools/testing/selftests/kvm/guest_memfd_test.c
[ ... ]
> @@ -541,12 +541,23 @@ static void test_resource_fd_tmpfs_huge(struct kvm_vm *vm)
> close(pool_fd);
> }
>
> -#define ____gmem_test(__test, __vm, __flags, __gmem_size, args...) \
> -do { \
> - int fd = vm_create_guest_memfd(__vm, __gmem_size, __flags); \
> - \
> - test_##__test(args); \
> - close(fd); \
> +#define ____gmem_test(__test, __vm, __flags, __gmem_size, args...) \
> +do { \
> + int pool_fd = -1; \
> + int fd; \
> + \
> + if ((__flags) & GUEST_MEMFD_FLAG_USE_RESOURCE) { \
> + pool_fd = create_tmpfs_pool_fd("never", true, __gmem_size); \
[Severity: Medium]
Does create_tmpfs_pool_fd() correctly handle when fsmount() returns 0?
Looking at create_tmpfs_pool_fd():
mnt_fd = syscall(__NR_fsmount, fs_fd, FSMOUNT_CLOEXEC, 0);
TEST_ASSERT(mnt_fd > 0, "fsmount failed");
While typically stdin, file descriptor 0 is valid. If fd 0 is allocated to the
new mount, a successful fsmount will trigger a false test failure because the
assertion strictly checks for mnt_fd > 0 instead of mnt_fd >= 0.
> + fd = vm_create_guest_memfd_resource(__vm, __gmem_size, \
> + __flags, pool_fd); \
> + } else { \
> + fd = vm_create_guest_memfd(__vm, __gmem_size, __flags); \
> + } \
[ ... ]
> @@ -606,15 +617,23 @@ static void test_guest_memfd(unsigned long vm_type)
> test_resource_fd_tmpfs_huge(vm);
>
> __test_guest_memfd(vm, 0);
> + __test_guest_memfd(vm, GUEST_MEMFD_FLAG_USE_RESOURCE);
[Severity: Medium]
Does this implicitly pass resource_fd=0 when testing the USE_RESOURCE flag?
Looking at test_create_guest_memfd_invalid_sizes(), which is called via
__test_guest_memfd():
fd = __vm_create_guest_memfd(vm, size, guest_memfd_flags);
TEST_ASSERT(fd < 0 && errno == EINVAL, ...);
Because __vm_create_guest_memfd() defaults to 0 for the resource_fd, it relies
entirely on kernel parameter validation ordering. If the kernel's parameter
validation evaluates resource_fd before size, this will unexpectedly return
EBADF or ENOTDIR (as fd 0 is typically not a valid tmpfs mount), causing false
test failures instead of the expected EINVAL for unaligned sizes.
[Severity: Medium]
Does this unconditionally execute the USE_RESOURCE tests without checking if the
flag is supported?
On older kernels, passing an unsupported flag returns -EINVAL. This will cause
test failures since the feature is not exposed via
vm_check_cap(KVM_CAP_GUEST_MEMFD_FLAGS) and skipped gracefully. For example,
test_resource_fd_invalid(), which is called just above this line, expects
-EBADF but will receive -EINVAL when the USE_RESOURCE flag is unrecognized:
fd = __vm_create_guest_memfd_resource(vm, page_size,
GUEST_MEMFD_FLAG_USE_RESOURCE, -1);
TEST_ASSERT(fd < 0, "guest_memfd with -1 resource_fd should fail");
TEST_ASSERT_EQ(errno, EBADF);
>
> flags = vm_check_cap(vm, KVM_CAP_GUEST_MEMFD_FLAGS);
> - if (flags & GUEST_MEMFD_FLAG_MMAP)
> + if (flags & GUEST_MEMFD_FLAG_MMAP) {
> __test_guest_memfd(vm, GUEST_MEMFD_FLAG_MMAP);
> + __test_guest_memfd(vm, GUEST_MEMFD_FLAG_MMAP |
> + GUEST_MEMFD_FLAG_USE_RESOURCE);
> + }
>
> /* MMAP should always be supported if INIT_SHARED is supported. */
> - if (flags & GUEST_MEMFD_FLAG_INIT_SHARED)
> + if (flags & GUEST_MEMFD_FLAG_INIT_SHARED) {
> __test_guest_memfd(vm, GUEST_MEMFD_FLAG_MMAP |
> GUEST_MEMFD_FLAG_INIT_SHARED);
> + __test_guest_memfd(vm, GUEST_MEMFD_FLAG_MMAP |
> + GUEST_MEMFD_FLAG_INIT_SHARED |
> + GUEST_MEMFD_FLAG_USE_RESOURCE);
> + }
>
> kvm_vm_free(vm);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260925-gmem-tmpfs-backend-v1-0-d36159822d18@google.com?part=11
next prev parent reply other threads:[~2026-09-26 1:02 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-26 0:50 [PATCH RFC 00/17] Allow guest_memfd to be created using a resource (pool) fd Ackerley Tng
2026-09-26 0:50 ` Ackerley Tng via B4 Relay
2026-09-26 0:50 ` [PATCH RFC 01/17] mm: shmem: Implement guest_memfd provider operations for tmpfs Ackerley Tng
2026-09-26 0:50 ` Ackerley Tng via B4 Relay
2026-09-26 1:08 ` sashiko-bot
2026-10-01 13:07 ` David Woodhouse
2026-10-01 14:17 ` Jason Gunthorpe
2026-10-01 15:47 ` David Woodhouse
2026-10-01 17:15 ` Jason Gunthorpe
2026-09-26 0:50 ` [PATCH RFC 02/17] KVM: guest_memfd: Support provider folio allocation Ackerley Tng
2026-09-26 0:50 ` Ackerley Tng via B4 Relay
2026-09-26 1:00 ` sashiko-bot
2026-09-26 0:50 ` [PATCH RFC 03/17] KVM: guest_memfd: Support provider folio invalidation Ackerley Tng
2026-09-26 0:50 ` Ackerley Tng via B4 Relay
2026-09-26 0:50 ` [PATCH RFC 04/17] KVM: guest_memfd: Add helper to attach resource provider file Ackerley Tng
2026-09-26 0:50 ` Ackerley Tng via B4 Relay
2026-09-26 1:13 ` sashiko-bot
2026-09-26 0:50 ` [PATCH RFC 05/17] KVM: selftests: Add helper to create guest_memfd with a resource file Ackerley Tng
2026-09-26 0:50 ` Ackerley Tng via B4 Relay
2026-09-26 1:00 ` sashiko-bot
2026-09-26 0:50 ` [PATCH RFC 06/17] KVM: selftests: Test negative validation of resource_fd argument Ackerley Tng
2026-09-26 0:50 ` Ackerley Tng via B4 Relay
2026-09-26 1:01 ` sashiko-bot
2026-09-26 0:50 ` [PATCH RFC 07/17] KVM: selftests: Test rejection of unsupported filesystem for resource_fd Ackerley Tng
2026-09-26 0:50 ` Ackerley Tng via B4 Relay
2026-09-26 0:56 ` sashiko-bot
2026-09-26 0:50 ` [PATCH RFC 08/17] KVM: selftests: Test rejection of tmpfs file " Ackerley Tng
2026-09-26 0:50 ` Ackerley Tng via B4 Relay
2026-09-26 0:50 ` [PATCH RFC 09/17] KVM: selftests: Test rejection of swap tmpfs mounts Ackerley Tng
2026-09-26 0:50 ` Ackerley Tng via B4 Relay
2026-09-26 0:57 ` sashiko-bot
2026-09-26 0:50 ` [PATCH RFC 10/17] KVM: selftests: Test rejection of hugepage " Ackerley Tng
2026-09-26 0:50 ` Ackerley Tng via B4 Relay
2026-09-26 0:58 ` sashiko-bot
2026-09-26 0:50 ` [PATCH RFC 11/17] KVM: selftests: Test guest_memfd with anonymous fsmount() tmpfs pool Ackerley Tng
2026-09-26 0:50 ` Ackerley Tng via B4 Relay
2026-09-26 1:02 ` sashiko-bot [this message]
2026-09-26 0:50 ` [PATCH RFC 12/17] KVM: selftests: Test guest_memfd with mounted tmpfs root directory Ackerley Tng
2026-09-26 0:50 ` Ackerley Tng via B4 Relay
2026-09-26 1:01 ` sashiko-bot
2026-09-26 0:51 ` [PATCH RFC 13/17] KVM: selftests: Test guest_memfd resource pool sharing across instances Ackerley Tng
2026-09-26 0:51 ` Ackerley Tng via B4 Relay
2026-09-26 0:51 ` [PATCH RFC 14/17] KVM: selftests: Test memory allocation against shared tmpfs resource pool Ackerley Tng
2026-09-26 0:51 ` Ackerley Tng via B4 Relay
2026-09-26 0:51 ` [PATCH RFC 15/17] KVM: selftests: Test that shared tmpfs resource pool size limit is respected Ackerley Tng
2026-09-26 0:51 ` Ackerley Tng via B4 Relay
2026-09-26 0:51 ` [PATCH RFC 16/17] KVM: selftests: Test guest execution with tmpfs-backed guest_memfd Ackerley Tng
2026-09-26 0:51 ` Ackerley Tng via B4 Relay
2026-09-26 1:07 ` sashiko-bot
2026-09-26 0:51 ` [PATCH RFC 17/17] KVM: selftests: Document testing TODOs Ackerley Tng
2026-09-26 0:51 ` Ackerley Tng via B4 Relay
2026-09-28 16:32 ` [PATCH RFC 00/17] Allow guest_memfd to be created using a resource (pool) fd David Woodhouse
2026-09-28 22:59 ` Ackerley Tng
2026-09-29 16:17 ` David Woodhouse
2026-09-29 23:41 ` Ackerley Tng
2026-09-30 0:08 ` David Woodhouse
2026-10-01 13:43 ` Gregory Price
2026-10-12 14:11 ` Ackerley Tng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260926010236.054251F0089A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=ackerleytng@google.com \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.