From: sashiko-bot@kernel.org
To: "Gregory Price" <gourry@gourry.net>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 5/5] selftests: KVM: guest_memfd: test GUEST_MEMFD_FLAG_BIND_NODE
Date: Wed, 02 Sep 2026 20:04:59 +0000 [thread overview]
Message-ID: <20260902200500.5703F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260902194657.79075-6-gourry@gourry.net>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The test `test_bind_node` assumes that NUMA nodes 0 and 1 always exist and are online, which will crash the test on systems with sparse NUMA topologies.
- [Medium] Skipping GUEST_MEMFD_FLAG_BIND_NODE unconditionally in test_guest_memfd_flags() omits testing its rejection on unsupported kernels.
--
commit bc5b1f010d9045d5cca04643d1e37516ee53b8b5
Author: Gregory Price <gourry@gourry.net>
selftests: KVM: guest_memfd: test GUEST_MEMFD_FLAG_BIND_NODE
This commit adds tests for the GUEST_MEMFD_FLAG_BIND_NODE flag in the KVM
guest_memfd selftest. It verifies behavior on NUMA setups, including
faulting onto remote nodes, and checks for invalid arguments. The flag
is skipped in the general test_guest_memfd_flags() loop as it requires
a valid node field.
> diff --git a/tools/testing/selftests/kvm/guest_memfd_test.c b/tools/testing/selftests/kvm/guest_memfd_test.c
> index 1818e0fea5690..b333cb42fab29 100644
> --- a/tools/testing/selftests/kvm/guest_memfd_test.c
> +++ b/tools/testing/selftests/kvm/guest_memfd_test.c
[ ... ]
> @@ -196,6 +196,83 @@ static void test_numa_allocation(int fd, size_t total_size)
> kvm_munmap(mem, total_size);
> }
>
> +static bool has_bind_node(struct kvm_vm *vm)
> +{
> + return vm_check_cap(vm, KVM_CAP_GUEST_MEMFD_FLAGS) &
> + GUEST_MEMFD_FLAG_BIND_NODE;
> +}
> +
[ ... ]
> +static void test_bind_node(int fd, size_t total_size, int node)
> +{
> + const unsigned long other_mask = 1UL << (node ? 0 : 1);
[Severity: Medium]
Does this code assume NUMA nodes 0 and 1 always exist and are online, which
could fail the test on systems with sparse NUMA topologies?
By hardcoding the "other" node as 1 (or 0) using
other_mask = 1UL << (node ? 0 : 1), the test assumes these nodes are always
present. On a multi-node system where node 0 is memoryless or only nodes 0
and 2 exist, wouldn't the kvm_set_mempolicy() or guest_memfd creation fail
with EINVAL?
> + const unsigned long maxnode = BITS_PER_TYPE(other_mask);
> + bool steer_away = is_multi_numa_node_system();
[ ... ]
> @@ -429,6 +506,10 @@ static void test_guest_memfd_flags(struct kvm_vm *vm)
> int fd;
>
> for (flag = BIT(0); flag; flag <<= 1) {
> + /* BIND_NODE depends on a valid node field, test separately */
> + if (flag == GUEST_MEMFD_FLAG_BIND_NODE)
> + continue;
> +
[Severity: Medium]
Does skipping this unconditionally omit testing its rejection on
unsupported kernels?
The loop in test_guest_memfd_flags() is designed to test that all
unsupported flags are correctly rejected with -EINVAL. By bypassing it
entirely with this continue statement, wouldn't this fail to verify
that older kernels without BIND_NODE actually reject the flag? Should
this instead only skip if (flag & valid_flags)?
> fd = __vm_create_guest_memfd(vm, page_size, flag);
> if (flag & valid_flags) {
> TEST_ASSERT(fd >= 0,
> @@ -486,6 +568,8 @@ static void __test_guest_memfd(struct kvm_vm *vm, u64 flags)
> gmem_test(mmap_supported, vm, flags);
> gmem_test(fault_overflow, vm, flags);
> gmem_test(numa_allocation, vm, flags);
> + if (has_bind_node(vm))
> + gmem_test_node(bind_node, vm, flags, 0);
[Severity: Medium]
Does hardcoding node 0 here cause the same sparse NUMA topology issue?
Similar to the logic in test_bind_node(), passing 0 as the node assumes
that NUMA node 0 always exists and is online. Could this crash the test on
systems where node 0 does not exist?
> __gmem_test(collapse, vm, flags, pmd_size);
> } else {
> gmem_test(fault_private, vm, flags);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260902194657.79075-1-gourry@gourry.net?part=5
next prev parent reply other threads:[~2026-09-02 20:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 19:46 [PATCH 0/5] KVM: guest_memfd: bind backing memory to a NUMA node Gregory Price
2026-09-02 19:46 ` [PATCH 1/5] mm/mempolicy: add mempolicy_create() Gregory Price
2026-09-02 19:46 ` [PATCH 2/5] mm/mempolicy: add mpol_set_shared_policy_range() Gregory Price
2026-09-02 19:46 ` [PATCH 3/5] KVM: guest_memfd: bind backing memory to a NUMA node at creation Gregory Price
2026-09-02 20:00 ` sashiko-bot
2026-09-02 19:46 ` [PATCH 4/5] selftests: KVM: guest_memfd: let the gmem_test() harness bind a node Gregory Price
2026-09-02 19:59 ` sashiko-bot
2026-09-02 19:46 ` [PATCH 5/5] selftests: KVM: guest_memfd: test GUEST_MEMFD_FLAG_BIND_NODE Gregory Price
2026-09-02 20:04 ` sashiko-bot [this message]
2026-09-09 22:41 ` [PATCH 0/5] KVM: guest_memfd: bind backing memory to a NUMA node Ackerley Tng
2026-09-09 23:10 ` Gregory Price
2026-09-09 23:23 ` Ackerley Tng
2026-09-09 23:41 ` Gregory Price
2026-09-10 11:32 ` David Hildenbrand (Arm)
2026-09-10 13:39 ` Gregory Price
2026-09-10 14:00 ` David Hildenbrand (Arm)
2026-09-10 11:30 ` David Hildenbrand (Arm)
2026-09-10 13:40 ` Gregory Price
2026-09-10 14:05 ` David Hildenbrand (Arm)
2026-09-10 14:46 ` Gregory Price
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=20260902200500.5703F1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=gourry@gourry.net \
--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.