From: sashiko-bot@kernel.org
To: "Like Xu" <like.xu.linux@gmail.com>
Cc: kvmarm@lists.linux.dev, "Oliver Upton" <oupton@kernel.org>,
kvm@vger.kernel.org, "Marc Zyngier" <maz@kernel.org>
Subject: Re: [PATCH v2 2/3] KVM: selftests: arm64: Skip sea_to_user without 1GB hugepages
Date: Tue, 18 Aug 2026 11:36:14 +0000 [thread overview]
Message-ID: <20260818113615.5CBE01F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260818112920.26252-3-likexu@tencent.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] get_free_hugepages() overestimates available hugepages by ignoring reserved pages, which allows the test to proceed and crash with ENOMEM on systems with reserved pools.
--
--- Patch [2]: [PATCH v2 2/3] KVM: selftests: arm64: Skip sea_to_user without 1GB hugepages ---
commit 5fa5666824342b3dd28a5ef6a04bb5ac183257c8
Author: Like Xu <like.xu.linux@gmail.com>
KVM: selftests: arm64: Skip sea_to_user without 1GB hugepages
This commit adds a check to skip the sea_to_user test if the host does not
have enough 1GB hugepages available, preventing a hard failure on systems
without an empty pool.
[ ... ]
> diff --git a/tools/testing/selftests/kvm/lib/test_util.c b/tools/testing/selftests/kvm/lib/test_util.c
> index bab1bd2b775b6..29f9c1d60b1b7 100644
> --- a/tools/testing/selftests/kvm/lib/test_util.c
> +++ b/tools/testing/selftests/kvm/lib/test_util.c
> @@ -222,6 +222,21 @@ size_t get_def_hugetlb_pagesz(void)
> TEST_FAIL("Error in reading /proc/meminfo");
> }
>
> +size_t get_free_hugepages(size_t page_size)
> +{
> + char path[128];
> + size_t free;
> +
> + snprintf(path, sizeof(path),
> + "/sys/kernel/mm/hugepages/hugepages-%zukB/free_hugepages",
> + page_size >> 10);
> + if (!test_sysfs_path(path))
> + return 0;
> +
> + free = get_sysfs_val(path);
> + return free * page_size;
[Severity: Medium]
Does this calculation overestimate the available hugepages by ignoring the
reserved pool?
The sysfs free_hugepages value includes pages that are already committed to
other mappings but not yet allocated (which are tracked via resv_hugepages).
If the test runs on a host where free_hugepages meets the VM_MEM_SIZE
requirement but some or all of those pages are reserved, the test will
incorrectly proceed and still crash with an -ENOMEM abort instead of cleanly
skipping.
Could we also read and subtract resv_hugepages to determine the actual
allocatable count?
> +}
> +
> #define ANON_FLAGS (MAP_PRIVATE | MAP_ANONYMOUS)
> #define ANON_HUGE_FLAGS (ANON_FLAGS | MAP_HUGETLB)
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260818112920.26252-1-likexu@tencent.com?part=2
next prev parent reply other threads:[~2026-08-18 11:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-18 11:29 [PATCH v2 0/3] KVM: selftests: arm64: Make sea_to_user skip cleanly Like Xu
2026-08-18 11:29 ` [PATCH v2 1/3] KVM: selftests: arm64: Fix EINJ handling in sea_to_user Like Xu
2026-08-18 11:29 ` [PATCH v2 2/3] KVM: selftests: arm64: Skip sea_to_user without 1GB hugepages Like Xu
2026-08-18 11:36 ` sashiko-bot [this message]
2026-08-18 12:49 ` Like Xu
2026-08-18 11:29 ` [PATCH v2 3/3] KVM: selftests: arm64: Skip sea_to_user when EINJ places no poison Like Xu
2026-08-18 11:41 ` sashiko-bot
2026-08-18 12:50 ` Like Xu
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=20260818113615.5CBE01F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=like.xu.linux@gmail.com \
--cc=maz@kernel.org \
--cc=oupton@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.