selftests/mm: avoid false failures in hugetlb and KSM tests

The KSM selftest uses conditional expressions to skip accesses to merge_across_nodes on systems without NUMA support. However, the ternary operator is combined with logical OR without parentheses:

a || numa_available() ? 0 : b || c

Due to operator precedence rules, this is parsed as:

(a || numa_available()) ? 0 : (b || c)

instead of the intended:

a || (numa_available() ? 0 : b) || c

Add parentheses around the conditional expressions to ensure the correct evaluation order.

Fixes 9aa1af954db0 ("selftests: vm: check numa_available() before operating "merge_across_nodes" in ksm_tests")

Signed-off-by Sayali Patil <[email protected]>

---

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 27477b28b74f ("selftests/mm: hugepage_settings: add APIs to get and set nr_hugepages")

Signed-off-by Sayali Patil <[email protected]>

---
 .../testing/selftests/mm/hugepage_settings.c  | 32 ++++++++++++++++++-
 .../testing/selftests/mm/hugepage_settings.h  |  1 +
 2 files changed, 32 insertions(+), 1 deletion(-)

tools/testing/selftests/mm/hugepage_settings.c +10 -0

index 2eab2110ac6a..ce38ae3da01a 100644
@@ -422,6 +422,36 @@ static void hugetlb_sysfs_path(char *buf, size_t buflen,
 		 size / 1024, attr);
 }
 
+void hugetlb_write_num(const char *path, unsigned long num)
+{
+	int fd, saved_errno;
+	ssize_t numwritten;
+	char buf[21];
+
+	sprintf(buf, "%lu", num);
+
+	fd = open(path, O_WRONLY);
+	if (fd == -1)

The KSM NUMA merge test allocates identical pages on different NUMA nodes and verifies KSM behavior with merge_across_nodes enabled and disabled.

On systems with memoryless NUMA nodes, for example:
#numactl -H

       available: 2 nodes (0,4)
       .....
       node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
       node 0 size: 14825 MB
       node 0 free: 1382 MB
       node 4 cpus:
       node 4 size: 0 MB
       node 4 free: 0 MB

the test may attempt to allocate memory on a node without memory, causing numa_alloc_onnode() to fail and resulting in a spurious test failure.

The test currently checks numa_num_configured_nodes() to determine whether sufficient NUMA nodes are available. However, configured nodes do not necessarily have memory.

Reuse the existing get_first_mem_node() and get_next_mem_node() helpers to locate NUMA nodes that actually contain memory, and skip the test when fewer than two such nodes are available.

Before patch:
---------------------------
running ./ksm_tests -N -m 1
---------------------------
mbind: Invalid argument
ok 1 KSM NUMA merging
Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
[PASS]
ok 1 ksm_tests -N -m 1
---------------------------
running ./ksm_tests -N -m 0
---------------------------
mbind: Invalid argument
not ok 1 KSM NUMA merging
Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0
[FAIL]
not ok 2 ksm_tests -N -m 0 # exit=1

After patch:
---------------------------
running ./ksm_tests -N -m 1
---------------------------
At least 2 NUMA nodes with memory must be available
ok 1
SKIP KSM NUMA merging
Totals: pass:0 fail:0 xfail:0 xpass:0 skip:1 error:0
[PASS]
ok 1 ksm_tests -N -m 1
---------------------------
running ./ksm_tests -N -m 0
---------------------------
At least 2 NUMA nodes with memory must be available
ok 1
SKIP KSM NUMA merging
Totals: pass:0 fail:0 xfail:0 xpass:0 skip:1 error:0
[PASS]
ok 2 ksm_tests -N -m 0

Fixes e3820ab252dd ("selftest/vm: fix ksm selftest to run with different NUMA topologies")

Co-developed-by David Hildenbrand (Arm) <[email protected]>

Signed-off-by David Hildenbrand (Arm) <[email protected]>

Signed-off-by Sayali Patil <[email protected]>

---
  tools/testing/selftests/mm/ksm_tests.c | 16 +++++++++-------
  1 file changed, 9 insertions(+), 7 deletions(-)

tools/testing/selftests/mm/ksm_tests.c +8 -5

index a050f4840cfa..2ebbb544c671 100644
@@ -440,9 +440,9 @@ static int get_next_mem_node(int node)
  		mem_node = i % (max_node + 1);
  		node_size = numa_node_size(mem_node, NULL);
  		if (node_size > 0)
-			break;
+			return mem_node;
  	}
-	return mem_node;
+	return -ENODEV;
  }
 
  static int get_first_mem_node(void)

@@ -455,8 +455,8 @@ static int check_ksm_numa_merge(int merge_type, int mapping, int prot, int timeo
  {
  	void *numa1_map_ptr, *numa2_map_ptr;
  	struct timespec start_time;
+	int first_node, second_node;
  	int page_count = 2;
-	int first_node;
 
  	if (clock_gettime(CLOCK_MONOTONIC_RAW, &start_time)) {
  		ksft_perror("clock_gettime");

@@ -467,17 +467,19 @@ static int check_ksm_numa_merge(int merge_type, int mapping, int prot, int timeo
  		ksft_print_msg("NUMA support not enabled\n");
  		return KSFT_SKIP;
  	}
-	if (numa_num_configured_nodes() <= 1) {
-		ksft_print_msg("At least 2 NUMA nodes must be available\n");
+	first_node = get_first_mem_node();
+	second_node = get_next_mem_node(first_node);
+
+	if (second_node < 0) {
+		ksft_print_msg("At least 2 NUMA nodes with memory must be available\n");
  		return KSFT_SKIP;
  	}
  	if (ksm_write_sysfs(KSM_FP("merge_across_nodes"), merge_across_nodes))

If get_first_mem_node() doesn't find a node with memory, will it return -ENODEV and pass it directly into get_next_mem_node()? Looking at get_next_mem_node() with a negative node parameter:

tools/testing/selftests/mm/ksm_tests.c:get_next_mem_node() {
   ...
   for (i = node + 1; i <= max_node + node; i++) {
       mem_node = i % (max_node + 1);
       node_size = numa_node_size(mem_node, NULL);
   ...
}

Because the modulo operator preserves the sign of a negative dividend, starting the loop with a negative node value causes mem_node to become negative. This means a negative node ID is then passed into libnuma's numa_node_size() function.
Could we check if first_node is valid before attempting to find the second node?

Quoted 67 lines · Sayali Patil

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 27477b28b74f ("selftests/mm: hugepage_settings: add APIs to get and set nr_hugepages")

Signed-off-by Sayali Patil <[email protected]>

---
  .../testing/selftests/mm/hugepage_settings.c  | 32 ++++++++++++++++++-
  .../testing/selftests/mm/hugepage_settings.h  |  1 +
  2 files changed, 32 insertions(+), 1 deletion(-)

tools/testing/selftests/mm/hugepage_settings.c +10 -0

index 2eab2110ac6a..ce38ae3da01a 100644
@@ -422,6 +422,36 @@ static void hugetlb_sysfs_path(char *buf, size_t buflen,
  		 size / 1024, attr);
  }
 
+void hugetlb_write_num(const char *path, unsigned long num)
+{
+	int fd, saved_errno;
+	ssize_t numwritten;
+	char buf[21];
+
+	sprintf(buf, "%lu", num);
+
+	fd = open(path, O_WRONLY);
+	if (fd == -1)

tools/testing/selftests/mm/hugepage_settings.c static void hugetlb_sysfs_path(char *buf, size_t buflen, · line 444

Quoted 10 lines

tools/testing/selftests/mm/hugepage_settings.c +10 -0

+		ksft_exit_fail_msg("%s open failed: %s\n", path, strerror(errno));
+
+	numwritten = write(fd, buf, strlen(buf));
+	saved_errno = errno;
+	close(fd);
+	errno = saved_errno;
+
+	/* Treat EINVAL as a skipped configuration (e.g., unsupported gigantic pages) */
+	if (numwritten < 0 && errno == EINVAL) {
+		ksft_print_msg("%s write(%s) failed: %s\n", path, buf, strerror(errno));

Should we even print anything here? Rather confusing. It's just like we cannot allocate anything (no memory).

In general, you are copy-pasting a lot of write_num()+write_file() content, which is really suboptimal.

All you want is an option for write_num -> write_file to skip on -EINVAL, correct?

There are not that many write_num / write_file users ...

Quoted 85 lines · David Hildenbrand (Arm)

Quoted 76 lines · Sayali Patil

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 27477b28b74f ("selftests/mm: hugepage_settings: add APIs to get and

set nr_hugepages")

Signed-off-by Sayali Patil <[email protected]>

---
  .../testing/selftests/mm/hugepage_settings.c  | 32 ++++++++++++++++++- .../testing/selftests/mm/hugepage_settings.h  |  1 +

  2 files changed, 32 insertions(+), 1 deletion(-)

tools/testing/ renamed from tools/testing/selftests/mm/hugepage_settings.c +0 -0

selftests/mm/hugepage_settings.c
index 2eab2110ac6a..ce38ae3da01a 100644

tools/testing/selftests/mm/hugepage_settings.c +17 -0

@@ -422,6 +422,36 @@ static void hugetlb_sysfs_path(char *buf, size_t buflen,
            size / 1024, attr);
   }
   +void hugetlb_write_num(const char *path, unsigned long num)
+{
+    int fd, saved_errno;
+    ssize_t numwritten;
+    char buf[21];
+
+    sprintf(buf, "%lu", num);
+
+    fd = open(path, O_WRONLY);
+    if (fd == -1)
+        ksft_exit_fail_msg("%s open failed: %s\n", path, strerror(errno));
+
+    numwritten = write(fd, buf, strlen(buf));
+    saved_errno = errno;
+    close(fd);
+    errno = saved_errno;
+
+    /* Treat EINVAL as a skipped configuration (e.g., unsupported gigantic

Quoted 4 lines

pages) */
+    if (numwritten < 0 && errno == EINVAL) {
+        ksft_print_msg("%s write(%s) failed: %s\n", path, buf, strerror(errno));

Should we even print anything here? Rather confusing. It's just like we cannot allocate anything (no memory).

Quoted 8 lines

In general, you are copy-pasting a lot of write_num()+write_file() content, which is really suboptimal.

All you want is an option for write_num -> write_file to skip on -EINVAL, correct?

There are not that many write_num / write_file users ...

Hi David,

Yes, all I need is to ignore the expected -EINVAL when attempting to configure gigantic hugepages via nr_hugepages.

I looked at extending write_num()/write_file() for this as in v1
(https://lore.kernel.org/
all/8bfa921e30eb94072685103f6496784aa23bb166.1782365671.git.sayalip@linux.ibm.com/), but these helpers are shared by several other selftests.
For example, write_file() is used by split_huge_page_test setup and by khugepaged tests for drop_caches, and is also used for various THP and khugepaged settings where -EINVAL would indicate a genuine setup failure. This concern was also raised during the v1 review.

Because the expected -EINVAL is specific to gigantic hugepage runtime allocation, I kept the handling local to the hugetlb setup path rather than changing the semantics of the common helpers.

I also agree that printing a message is not particularly useful in this case, and we can simply return without emitting any output.

Quoted 111 lines · Sayali Patil

Quoted 85 lines · David Hildenbrand (Arm)

Quoted 76 lines · Sayali Patil

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 27477b28b74f ("selftests/mm: hugepage_settings: add APIs to get and

set nr_hugepages")

Signed-off-by Sayali Patil <[email protected]>

---
   .../testing/selftests/mm/hugepage_settings.c  | 32 ++++++++++++++++++-
   .../testing/selftests/mm/hugepage_settings.h  |  1 +
   2 files changed, 32 insertions(+), 1 deletion(-)

tools/testing/ renamed from tools/testing/selftests/mm/hugepage_settings.c +0 -0

selftests/mm/hugepage_settings.c
index 2eab2110ac6a..ce38ae3da01a 100644

tools/testing/selftests/mm/hugepage_settings.c +17 -0

@@ -422,6 +422,36 @@ static void hugetlb_sysfs_path(char *buf, size_t buflen,
            size / 1024, attr);
   }
   +void hugetlb_write_num(const char *path, unsigned long num)
+{
+    int fd, saved_errno;
+    ssize_t numwritten;
+    char buf[21];
+
+    sprintf(buf, "%lu", num);
+
+    fd = open(path, O_WRONLY);
+    if (fd == -1)
+        ksft_exit_fail_msg("%s open failed: %s\n", path, strerror(errno));
+
+    numwritten = write(fd, buf, strlen(buf));
+    saved_errno = errno;
+    close(fd);
+    errno = saved_errno;
+
+    /* Treat EINVAL as a skipped configuration (e.g., unsupported gigantic

Quoted 4 lines

pages) */
+    if (numwritten < 0 && errno == EINVAL) {
+        ksft_print_msg("%s write(%s) failed: %s\n", path, buf, strerror(errno));

Should we even print anything here? Rather confusing. It's just like we cannot allocate anything (no memory).

Quoted 8 lines

In general, you are copy-pasting a lot of write_num()+write_file() content, which is really suboptimal.

All you want is an option for write_num -> write_file to skip on -EINVAL, correct?

There are not that many write_num / write_file users ...

Hi David,

Yes, all I need is to ignore the expected -EINVAL when attempting to configure gigantic hugepages via nr_hugepages.

I looked at extending write_num()/write_file() for this as in v1
(https://lore.kernel.org/
all/8bfa921e30eb94072685103f6496784aa23bb166.1782365671.git.sayalip@linux.ibm.com/), but these helpers are shared by several other selftests.
For example, write_file() is used by split_huge_page_test setup and by khugepaged tests for drop_caches, and is also used for various THP and khugepaged settings where -EINVAL would indicate a genuine setup failure. This concern was also raised during the v1 review.

Quoted 6 lines

Because the expected -EINVAL is specific to gigantic hugepage runtime allocation, I kept the handling local to the hugetlb setup path rather than changing the semantics of the common helpers.

I also agree that printing a message is not particularly useful in this case, and we can simply return without emitting any output.

We can either convert the functions to use flags, or hide it in some internal helpers, like the following:

From 1b1b8ad51f1f0be469cb191736300254b9521fe4 Mon Sep 17 00:00:00 2001
From: "David Hildenbrand (Arm)" <[email protected]>
Date: Wed, 1 Jul 2026 10:45:16 +0200
Subject: [PATCH] tmp

Signed-off-by David Hildenbrand (Arm) <[email protected]>

---
  tools/testing/selftests/mm/vm_util.c | 28 ++++++++++++++++++++++++----
  tools/testing/selftests/mm/vm_util.h |  1 +
  2 files changed, 25 insertions(+), 4 deletions(-)

tools/testing/selftests/mm/vm_util.c +24 -4

index 311fc5b4513eb..362070f817e9b 100644
@@ -719,7 +719,8 @@ int read_file(const char *path, char *buf, size_t buflen)
  	return (unsigned int) numread;
  }
 
-void write_file(const char *path, const char *buf, size_t buflen)
+static int __write_file(const char *path, const char *buf, size_t buflen,
+		bool ignore_einval)
  {
  	int fd, saved_errno;
  	ssize_t numwritten;

@@ -735,14 +736,23 @@ void write_file(const char *path, const char *buf, size_t buflen)
  	saved_errno = errno;
  	close(fd);
  	errno = saved_errno;
-	if (numwritten < 0)
+
+	if (numwritten < 0) {
+		if (ignore_einval && errno == EINVAL)
+			return;
  		ksft_exit_fail_msg("%s write(%.*s) failed: %s\n", path, (int)(buflen - 1),
  				buf, strerror(errno));
+	}
  	if (numwritten != buflen - 1)
  		ksft_exit_fail_msg("%s write(%.*s) is truncated, expected %zu bytes, got %zd bytes\n",
  				path, (int)(buflen - 1), buf, buflen - 1, numwritten);
  }
 
+static void write_file(const char *path, const char *buf, size_t buflen)
+{
+	__write_file(path, bug, buflen, /* ignore_einval = */ false);
+}
+
  unsigned long read_num(const char *path)
  {
  	char buf[21];

@@ -753,12 +763,22 @@ unsigned long read_num(const char *path)
  	return strtoul(buf, NULL, 10);
  }
 
-void write_num(const char *path, unsigned long num)
+static void __write_num(const char *path, unsigned long num, bool ignore_einval)
  {
  	char buf[21];
 
  	sprintf(buf, "%lu", num);
-	write_file(path, buf, strlen(buf) + 1);
+	write_file(path, buf, strlen(buf) + 1, ignore_einval);
+}
+
+void write_num(const char *path, unsigned long num)
+{
+	return __write_num(path, num, /* ignore_einval = */ false);
+}
+
+void write_num_ignore_einval(const char *path, unsigned long num)
+{
+	return __write_num(path, num, /* ignore_einval = */ true);
  }
 
  static unsigned long shmall, shmmax;

tools/testing/selftests/mm/vm_util.h +0 -0

index ea8fc8fdf0eb0..7799154b67eed 100644