All of lore.kernel.org
 help / color / mirror / Atom feed
From: Like Xu <like.xu.linux@gmail.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.linux.dev, Oliver Upton <oupton@kernel.org>,
	kvm@vger.kernel.org, sashiko-reviews@lists.linux.dev
Subject: Re: [PATCH v2 2/3] KVM: selftests: arm64: Skip sea_to_user without 1GB hugepages
Date: Tue, 18 Aug 2026 20:49:21 +0800	[thread overview]
Message-ID: <4f7023b4-dd7a-47cb-9754-52e6d41d3aa1@gmail.com> (raw)
In-Reply-To: <20260818113615.5CBE01F000E9@smtp.kernel.org>

On 8/18/26 7:36 PM, sashiko-bot@kernel.org wrote:
> 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?

For any human to double check:

diff --git a/tools/testing/selftests/kvm/arm64/sea_to_user.c 
b/tools/testing/selftests/kvm/arm64/sea_to_user.c
index 1c2a743ca8e23..7cf95da8e594d 100644
--- a/tools/testing/selftests/kvm/arm64/sea_to_user.c
+++ b/tools/testing/selftests/kvm/arm64/sea_to_user.c
@@ -281,6 +281,12 @@ static struct kvm_vm 
*vm_create_with_sea_handler(struct kvm_vcpu **vcpu)
  	alignment = max(backing_page_size, guest_page_size);
  	num_guest_pages = VM_MEM_SIZE / guest_page_size;

+	/*
+	 * The region is backed by 1GB hugepages; skip gracefully rather than
+	 * failing with mmap() -ENOMEM if the host has none reserved.
+	 */
+	TEST_REQUIRE(get_free_hugepages(backing_page_size) >= VM_MEM_SIZE);
+
  	vm = __vm_create_with_one_vcpu(vcpu, num_guest_pages, guest_code);
  	vm_init_descriptor_tables(vm);
  	vcpu_init_descriptor_tables(*vcpu);
diff --git a/tools/testing/selftests/kvm/include/test_util.h 
b/tools/testing/selftests/kvm/include/test_util.h
index a56271c237ae9..0624922c2735d 100644
--- a/tools/testing/selftests/kvm/include/test_util.h
+++ b/tools/testing/selftests/kvm/include/test_util.h
@@ -168,6 +168,7 @@ struct vm_mem_backing_src_alias {
  bool thp_configured(void);
  size_t get_trans_hugepagesz(void);
  size_t get_def_hugetlb_pagesz(void);
+size_t get_free_hugepages(size_t page_size);
  const struct vm_mem_backing_src_alias *vm_mem_backing_src_alias(u32 i);
  size_t get_backing_src_pagesz(u32 i);
  bool is_backing_src_hugetlb(u32 i);
diff --git a/tools/testing/selftests/kvm/lib/test_util.c 
b/tools/testing/selftests/kvm/lib/test_util.c
index bab1bd2b775b6..3bff9d825e8af 100644
--- a/tools/testing/selftests/kvm/lib/test_util.c
+++ b/tools/testing/selftests/kvm/lib/test_util.c
@@ -222,6 +222,32 @@ 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, resv;
+
+	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);
+
+	/*
+	 * free_hugepages still counts pages that are reserved by existing
+	 * mappings but not yet faulted in, so only free minus resv can back a
+	 * new reservation (see available_huge_pages() in mm/hugetlb.c). Ignore
+	 * surplus/overcommit: it does not apply to gigantic pages at runtime.
+	 */
+	snprintf(path, sizeof(path),
+		 "/sys/kernel/mm/hugepages/hugepages-%zukB/resv_hugepages",
+		 page_size >> 10);
+	resv = test_sysfs_path(path) ? get_sysfs_val(path) : 0;
+
+	return free > resv ? (free - resv) * page_size : 0;
+}
+
  #define ANON_FLAGS	(MAP_PRIVATE | MAP_ANONYMOUS)
  #define ANON_HUGE_FLAGS	(ANON_FLAGS | MAP_HUGETLB)

> 
>> +}
>> +
>>   #define ANON_FLAGS	(MAP_PRIVATE | MAP_ANONYMOUS)
>>   #define ANON_HUGE_FLAGS	(ANON_FLAGS | MAP_HUGETLB)
>>
> 


  reply	other threads:[~2026-08-18 12:49 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
2026-08-18 12:49     ` Like Xu [this message]
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=4f7023b4-dd7a-47cb-9754-52e6d41d3aa1@gmail.com \
    --to=like.xu.linux@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --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.