Re: [PATCH 1/2] selftests/mm: handle EINVAL when configuring gigantic hugepages

On 26/06/26 20:18, Usama Arif wrote:

On Thu, 25 Jun 2026 18:10:16 +0530 Sayali Patil [off-list ref] wrote:

quoted

Some MM selftests attempt to configure the amount of
HugeTLB pages of different sizes by writing to nr_hugepages.

PowerPC hash MMU pSeries systems advertise gigantic hugepage sizes
but do not support runtime allocation of such pages, writes
to the corresponding nr_hugepages file fail with -EINVAL.
This causes the test to bail out even though the failure is due
to a platform limitation rather than the
functionality being tested.

Treat -EINVAL from the sysfs write as a skipped configuration request
and continue running the test instead of failing.

Before patch:
    -------------------------
    running ./hugetlb-madvise
    -------------------------
    TAP version 13
    1..1
      [INFO] detected hugetlb page size: 16777216 KiB
      [INFO] detected hugetlb page size: 16384 KiB
     ok 1 MADV_DONTNEED and MADV_REMOVE on hugetlb
     Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
     Bail out! /sys/kernel/mm/hugepages/hugepages-16777216kB/nr_hugepages
     write(0) failed: Invalid argument
     Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0
     [FAIL]

After patch:
    -------------------------
    running ./hugetlb-madvise
    -------------------------
    TAP version 13
    1..1
     [INFO] detected hugetlb page size: 16777216 KiB
     [INFO] detected hugetlb page size: 16384 KiB
    ok 1 MADV_DONTNEED and MADV_REMOVE on hugetlb
    Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
    /sys/kernel/mm/hugepages/hugepages-16777216kB/nr_hugepages
    write(0) failed: Invalid argument
    [PASS]

Fixes: 9d07250ea1eb ("selftests/mm: hugepage_settings: add APIs to get and set nr_hugepages")
Signed-off-by: Sayali Patil <redacted>
---
  tools/testing/selftests/mm/vm_util.c | 7 +++++++
  1 file changed, 7 insertions(+)

diff --git a/tools/testing/selftests/mm/vm_util.c b/tools/testing/selftests/mm/vm_util.c
index 311fc5b4513e..a8f16eef5c7c 100644
--- a/tools/testing/selftests/mm/vm_util.c
+++ b/tools/testing/selftests/mm/vm_util.c

@@ -735,6 +735,13 @@ void write_file(const char *path, const char *buf, size_t buflen)
  	saved_errno = errno;
  	close(fd);
  	errno = saved_errno;
+
+	if (numwritten < 0 && errno == EINVAL) {
+		ksft_print_msg("%s write(%.*s) failed: %s\n", path,
+			       (int)(buflen - 1), buf, strerror(errno));
+		return;
+	}
+

This makes write_file() silently succeed for every EINVAL, not just the
gigantic-hugetlb setup case. Several callers use this helper for writes where
EINVAL is a real test failure, for example drop_caches or split huge page
setup. Those tests can now continue after a failed setup and report misleading
results.

Please keep the common helper strict and ignore EINVAL only in the hugetlb
path that is probing unsupported gigantic page runtime allocation.

Thanks for review!
In v2, I kept the generic write_file() helper unchanged and
added a dedicated hugetlb_write_num() helper to handle the expected
-EINVAL returned when configuring gigantic hugepages. This limits the
special handling to the hugepage setup path and avoids masking genuine
EINVAL failures from other write_file() callers.

V2: 
https://lore.kernel.org/all/3d394c8cd59fe380d4e2d13b051544f241918f07.1782811071.git.sayalip@linux.ibm.com/ (local)

quoted

  	if (numwritten < 0)
  		ksft_exit_fail_msg("%s write(%.*s) failed: %s\n", path, (int)(buflen - 1),
  				buf, strerror(errno));
-- 
2.52.0