[PATCH v2 0/7] selftests/mm: Fix false positives and skip unsupported tests

[PATCH v2 0/7] selftests/mm: Fix false positives and skip unsupported tests

[Aboorva Devarajan]

Hi all,

This patch series addresses false positives in the generic mm selftests
and skips tests that cannot run correctly due to missing features or system
limitations.

---

v1: https://lore.kernel.org/all/20250616160632.35250-1-aboorvad@linux.ibm.com/

Changes in v2:

   - Rebased onto the mm-new branch, top commit of the base is 3b4a8ad89f7e ("mm: add zblock allocator").
   - Split some patches for clarity.
   - Updated virtual_address_range test to support testing 4PB VA on PPC64.
   - Added proper Fixes: tags.
   - Included a patch to skip a failing userfaultfd test when unsupported,
     instead of reporting a failure.

---

Please let us know if you have any further comments.

Thanks,
Aboorva

Aboorva Devarajan (3):
  selftests/mm: Fix child process exit codes in ksm_functional_tests
  selftests/mm: Skip thuge-gen if shmmax is too small or no 1G huge
    pages
  selftests/mm: Skip hugepage-mremap test if userfaultfd unavailable

Donet Tom (4):
  mm/selftests: Fix incorrect pointer being passed to mark_range()
  selftests/mm: Add support to test 4PB VA on PPC64
  selftest/mm: Fix ksm_funtional_test failures
  mm/selftests: Fix split_huge_page_test failure on systems with 64KB
    page size

 tools/testing/selftests/mm/hugepage-mremap.c  | 16 ++++++++++---
 .../selftests/mm/ksm_functional_tests.c       | 24 +++++++++++++------
 .../selftests/mm/split_huge_page_test.c       | 23 +++++++++++++-----
 tools/testing/selftests/mm/thuge-gen.c        | 11 +++++----
 .../selftests/mm/virtual_address_range.c      |  8 ++++++-
 5 files changed, 61 insertions(+), 21 deletions(-)

-- 
2.43.5

[PATCH v2 1/7] mm/selftests: Fix incorrect pointer being passed to mark_range()

[Aboorva Devarajan]

From: Donet Tom <donettom@linux.ibm.com>

In main(), the high address is stored in hptr, but for mark_range(),
the address passed is ptr, not hptr. Fixed this by changing ptr[i] to
hptr[i] in mark_range() function call.

Fixes: b2a79f62133a ("selftests/mm: virtual_address_range: unmap chunks after validation")
Signed-off-by: Donet Tom <donettom@linux.ibm.com>
Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
---
 tools/testing/selftests/mm/virtual_address_range.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/mm/virtual_address_range.c b/tools/testing/selftests/mm/virtual_address_range.c
index 169dbd692bf5..e24c36a39f22 100644
--- a/tools/testing/selftests/mm/virtual_address_range.c
+++ b/tools/testing/selftests/mm/virtual_address_range.c
@@ -227,7 +227,7 @@ int main(int argc, char *argv[])
 		if (hptr[i] == MAP_FAILED)
 			break;
 
-		mark_range(ptr[i], MAP_CHUNK_SIZE);
+		mark_range(hptr[i], MAP_CHUNK_SIZE);
 		validate_addr(hptr[i], 1);
 	}
 	hchunks = i;
-- 
2.43.5

Re: [PATCH v2 1/7] mm/selftests: Fix incorrect pointer being passed to mark_range()

[Dev Jain]

On 03/07/25 11:36 am, Aboorva Devarajan wrote:
> From: Donet Tom <donettom@linux.ibm.com>
>
> In main(), the high address is stored in hptr, but for mark_range(),
> the address passed is ptr, not hptr. Fixed this by changing ptr[i] to
> hptr[i] in mark_range() function call.
>
> Fixes: b2a79f62133a ("selftests/mm: virtual_address_range: unmap chunks after validation")
> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
> ---
>   tools/testing/selftests/mm/virtual_address_range.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/mm/virtual_address_range.c b/tools/testing/selftests/mm/virtual_address_range.c
> index 169dbd692bf5..e24c36a39f22 100644
> --- a/tools/testing/selftests/mm/virtual_address_range.c
> +++ b/tools/testing/selftests/mm/virtual_address_range.c
> @@ -227,7 +227,7 @@ int main(int argc, char *argv[])
>   		if (hptr[i] == MAP_FAILED)
>   			break;
>   
> -		mark_range(ptr[i], MAP_CHUNK_SIZE);
> +		mark_range(hptr[i], MAP_CHUNK_SIZE);
>   		validate_addr(hptr[i], 1);
>   	}
>   	hchunks = i;

Makes sense.

Reviewed-by: Dev Jain <dev.jain@arm.com>

Re: [PATCH v2 1/7] mm/selftests: Fix incorrect pointer being passed to mark_range()

[David Hildenbrand]

On 03.07.25 08:06, Aboorva Devarajan wrote:
> From: Donet Tom <donettom@linux.ibm.com>
> 
> In main(), the high address is stored in hptr, but for mark_range(),
> the address passed is ptr, not hptr. Fixed this by changing ptr[i] to
> hptr[i] in mark_range() function call.
> 
> Fixes: b2a79f62133a ("selftests/mm: virtual_address_range: unmap chunks after validation")
> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
> ---
>   tools/testing/selftests/mm/virtual_address_range.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/mm/virtual_address_range.c b/tools/testing/selftests/mm/virtual_address_range.c
> index 169dbd692bf5..e24c36a39f22 100644
> --- a/tools/testing/selftests/mm/virtual_address_range.c
> +++ b/tools/testing/selftests/mm/virtual_address_range.c
> @@ -227,7 +227,7 @@ int main(int argc, char *argv[])
>   		if (hptr[i] == MAP_FAILED)
>   			break;
>   
> -		mark_range(ptr[i], MAP_CHUNK_SIZE);
> +		mark_range(hptr[i], MAP_CHUNK_SIZE);
>   		validate_addr(hptr[i], 1);
>   	}
>   	hchunks = i;

Acked-by: David Hildenbrand <david@redhat.com>

-- 
Cheers,

David / dhildenb

Re: [PATCH v2 1/7] mm/selftests: Fix incorrect pointer being passed to mark_range()

[Zi Yan]

On 3 Jul 2025, at 2:06, Aboorva Devarajan wrote:

> From: Donet Tom <donettom@linux.ibm.com>
>
> In main(), the high address is stored in hptr, but for mark_range(),
> the address passed is ptr, not hptr. Fixed this by changing ptr[i] to
> hptr[i] in mark_range() function call.
>
> Fixes: b2a79f62133a ("selftests/mm: virtual_address_range: unmap chunks after validation")
> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
> ---
>  tools/testing/selftests/mm/virtual_address_range.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/mm/virtual_address_range.c b/tools/testing/selftests/mm/virtual_address_range.c
> index 169dbd692bf5..e24c36a39f22 100644
> --- a/tools/testing/selftests/mm/virtual_address_range.c
> +++ b/tools/testing/selftests/mm/virtual_address_range.c
> @@ -227,7 +227,7 @@ int main(int argc, char *argv[])
>  		if (hptr[i] == MAP_FAILED)
>  			break;
>
> -		mark_range(ptr[i], MAP_CHUNK_SIZE);
> +		mark_range(hptr[i], MAP_CHUNK_SIZE);
>  		validate_addr(hptr[i], 1);
>  	}
>  	hchunks = i;

It looks like it was a copy-paste error. Thank you for fixing it.

Reviewed-by: Zi Yan <ziy@nvidia.com>

Best Regards,
Yan, Zi

[PATCH v2 2/7] selftests/mm: Add support to test 4PB VA on PPC64

[Aboorva Devarajan]

From: Donet Tom <donettom@linux.ibm.com>

PowerPC64 supports a 4PB virtual address space, but this test was
previously limited to 512TB. This patch extends the coverage up to
the full 4PB VA range on PowerPC64.

Memory from 0 to 128TB is allocated without an address hint, while
allocations from 128TB to 4PB use a hint address.

Signed-off-by: Donet Tom <donettom@linux.ibm.com>
Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
---
 tools/testing/selftests/mm/virtual_address_range.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/tools/testing/selftests/mm/virtual_address_range.c b/tools/testing/selftests/mm/virtual_address_range.c
index e24c36a39f22..619acf0b9239 100644
--- a/tools/testing/selftests/mm/virtual_address_range.c
+++ b/tools/testing/selftests/mm/virtual_address_range.c
@@ -50,6 +50,7 @@
 #define NR_CHUNKS_256TB   (NR_CHUNKS_128TB * 2UL)
 #define NR_CHUNKS_384TB   (NR_CHUNKS_128TB * 3UL)
 #define NR_CHUNKS_3840TB  (NR_CHUNKS_128TB * 30UL)
+#define NR_CHUNKS_3968TB  (NR_CHUNKS_128TB * 31UL)
 
 #define ADDR_MARK_128TB  (1UL << 47) /* First address beyond 128TB */
 #define ADDR_MARK_256TB  (1UL << 48) /* First address beyond 256TB */
@@ -59,6 +60,11 @@
 #define HIGH_ADDR_SHIFT 49
 #define NR_CHUNKS_LOW   NR_CHUNKS_256TB
 #define NR_CHUNKS_HIGH  NR_CHUNKS_3840TB
+#elif defined(__PPC64__)
+#define HIGH_ADDR_MARK  ADDR_MARK_128TB
+#define HIGH_ADDR_SHIFT 48
+#define NR_CHUNKS_LOW   NR_CHUNKS_128TB
+#define NR_CHUNKS_HIGH  NR_CHUNKS_3968TB
 #else
 #define HIGH_ADDR_MARK  ADDR_MARK_128TB
 #define HIGH_ADDR_SHIFT 48
-- 
2.43.5

Re: [PATCH v2 2/7] selftests/mm: Add support to test 4PB VA on PPC64

[Dev Jain]

On 03/07/25 11:36 am, Aboorva Devarajan wrote:
> From: Donet Tom <donettom@linux.ibm.com>
>
> PowerPC64 supports a 4PB virtual address space, but this test was
> previously limited to 512TB. This patch extends the coverage up to
> the full 4PB VA range on PowerPC64.
>
> Memory from 0 to 128TB is allocated without an address hint, while
> allocations from 128TB to 4PB use a hint address.
>
> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
> ---

Would have saved us a lot of time if we had figured out that
the problem wasn't the gap logic but the large VA space support,
anyhow digging down that rabbit hole gave me some knowledge
on VMA allocation stuff : )

Reviewed-by: Dev Jain <dev.jain@arm.com>

Re: [PATCH v2 2/7] selftests/mm: Add support to test 4PB VA on PPC64

[David Hildenbrand]

On 03.07.25 08:06, Aboorva Devarajan wrote:
> From: Donet Tom <donettom@linux.ibm.com>
> 
> PowerPC64 supports a 4PB virtual address space, but this test was
> previously limited to 512TB. This patch extends the coverage up to
> the full 4PB VA range on PowerPC64.
> 
> Memory from 0 to 128TB is allocated without an address hint, while
> allocations from 128TB to 4PB use a hint address.
> 
> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>

Comment applies to all patches in this series:

See Documentation/process/submitting-patches.rst, in particular "Example 
of a patch submitted by a Co-developed-by: author::"

If you are a co-developer of any of these patches (and not simply resend 
them without touching them), you should have a

Co-developed-by: Aboorva Devarajan <aboorvad@linux.ibm.com>

above your Signed-off-by


> ---
>   tools/testing/selftests/mm/virtual_address_range.c | 6 ++++++
>   1 file changed, 6 insertions(+)
> 
> diff --git a/tools/testing/selftests/mm/virtual_address_range.c b/tools/testing/selftests/mm/virtual_address_range.c
> index e24c36a39f22..619acf0b9239 100644
> --- a/tools/testing/selftests/mm/virtual_address_range.c
> +++ b/tools/testing/selftests/mm/virtual_address_range.c
> @@ -50,6 +50,7 @@
>   #define NR_CHUNKS_256TB   (NR_CHUNKS_128TB * 2UL)
>   #define NR_CHUNKS_384TB   (NR_CHUNKS_128TB * 3UL)
>   #define NR_CHUNKS_3840TB  (NR_CHUNKS_128TB * 30UL)
> +#define NR_CHUNKS_3968TB  (NR_CHUNKS_128TB * 31UL)
>   
>   #define ADDR_MARK_128TB  (1UL << 47) /* First address beyond 128TB */
>   #define ADDR_MARK_256TB  (1UL << 48) /* First address beyond 256TB */
> @@ -59,6 +60,11 @@
>   #define HIGH_ADDR_SHIFT 49
>   #define NR_CHUNKS_LOW   NR_CHUNKS_256TB
>   #define NR_CHUNKS_HIGH  NR_CHUNKS_3840TB
> +#elif defined(__PPC64__)
> +#define HIGH_ADDR_MARK  ADDR_MARK_128TB
> +#define HIGH_ADDR_SHIFT 48
> +#define NR_CHUNKS_LOW   NR_CHUNKS_128TB
> +#define NR_CHUNKS_HIGH  NR_CHUNKS_3968TB
>   #else
>   #define HIGH_ADDR_MARK  ADDR_MARK_128TB
>   #define HIGH_ADDR_SHIFT 48


Acked-by: David Hildenbrand <david@redhat.com>

-- 
Cheers,

David / dhildenb

Re: [PATCH v2 2/7] selftests/mm: Add support to test 4PB VA on PPC64

[Zi Yan]

On 3 Jul 2025, at 2:06, Aboorva Devarajan wrote:

> From: Donet Tom <donettom@linux.ibm.com>
>
> PowerPC64 supports a 4PB virtual address space, but this test was
> previously limited to 512TB. This patch extends the coverage up to
> the full 4PB VA range on PowerPC64.
>
> Memory from 0 to 128TB is allocated without an address hint, while
> allocations from 128TB to 4PB use a hint address.
>
> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
> ---
>  tools/testing/selftests/mm/virtual_address_range.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/tools/testing/selftests/mm/virtual_address_range.c b/tools/testing/selftests/mm/virtual_address_range.c
> index e24c36a39f22..619acf0b9239 100644
> --- a/tools/testing/selftests/mm/virtual_address_range.c
> +++ b/tools/testing/selftests/mm/virtual_address_range.c
> @@ -50,6 +50,7 @@
>  #define NR_CHUNKS_256TB   (NR_CHUNKS_128TB * 2UL)
>  #define NR_CHUNKS_384TB   (NR_CHUNKS_128TB * 3UL)
>  #define NR_CHUNKS_3840TB  (NR_CHUNKS_128TB * 30UL)
> +#define NR_CHUNKS_3968TB  (NR_CHUNKS_128TB * 31UL)
>
>  #define ADDR_MARK_128TB  (1UL << 47) /* First address beyond 128TB */
>  #define ADDR_MARK_256TB  (1UL << 48) /* First address beyond 256TB */
> @@ -59,6 +60,11 @@
>  #define HIGH_ADDR_SHIFT 49
>  #define NR_CHUNKS_LOW   NR_CHUNKS_256TB
>  #define NR_CHUNKS_HIGH  NR_CHUNKS_3840TB
> +#elif defined(__PPC64__)
> +#define HIGH_ADDR_MARK  ADDR_MARK_128TB
> +#define HIGH_ADDR_SHIFT 48
> +#define NR_CHUNKS_LOW   NR_CHUNKS_128TB
> +#define NR_CHUNKS_HIGH  NR_CHUNKS_3968TB
>  #else
>  #define HIGH_ADDR_MARK  ADDR_MARK_128TB
>  #define HIGH_ADDR_SHIFT 48

Could you also update the comment above this code to say PowerPC64 also
supports 4PB virtual address space?

From the comment, arm64 supports 4PB but its NR_CHUNKS_HIGH is only 3840TB,
whereas PowerPC64 here can get to 3968TB. I do not know why arm64’s
4PB is smaller. ;)

Otherwise, the patch looks good to me.

Reviewed-by: Zi Yan <ziy@nvidia.com>

Best Regards,
Yan, Zi

Re: [PATCH v2 2/7] selftests/mm: Add support to test 4PB VA on PPC64

[Dev Jain]

On 03/07/25 8:11 pm, Zi Yan wrote:
> On 3 Jul 2025, at 2:06, Aboorva Devarajan wrote:
>
>> From: Donet Tom <donettom@linux.ibm.com>
>>
>> PowerPC64 supports a 4PB virtual address space, but this test was
>> previously limited to 512TB. This patch extends the coverage up to
>> the full 4PB VA range on PowerPC64.
>>
>> Memory from 0 to 128TB is allocated without an address hint, while
>> allocations from 128TB to 4PB use a hint address.
>>
>> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
>> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
>> ---
>>   tools/testing/selftests/mm/virtual_address_range.c | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/tools/testing/selftests/mm/virtual_address_range.c b/tools/testing/selftests/mm/virtual_address_range.c
>> index e24c36a39f22..619acf0b9239 100644
>> --- a/tools/testing/selftests/mm/virtual_address_range.c
>> +++ b/tools/testing/selftests/mm/virtual_address_range.c
>> @@ -50,6 +50,7 @@
>>   #define NR_CHUNKS_256TB   (NR_CHUNKS_128TB * 2UL)
>>   #define NR_CHUNKS_384TB   (NR_CHUNKS_128TB * 3UL)
>>   #define NR_CHUNKS_3840TB  (NR_CHUNKS_128TB * 30UL)
>> +#define NR_CHUNKS_3968TB  (NR_CHUNKS_128TB * 31UL)
>>
>>   #define ADDR_MARK_128TB  (1UL << 47) /* First address beyond 128TB */
>>   #define ADDR_MARK_256TB  (1UL << 48) /* First address beyond 256TB */
>> @@ -59,6 +60,11 @@
>>   #define HIGH_ADDR_SHIFT 49
>>   #define NR_CHUNKS_LOW   NR_CHUNKS_256TB
>>   #define NR_CHUNKS_HIGH  NR_CHUNKS_3840TB
>> +#elif defined(__PPC64__)
>> +#define HIGH_ADDR_MARK  ADDR_MARK_128TB
>> +#define HIGH_ADDR_SHIFT 48
>> +#define NR_CHUNKS_LOW   NR_CHUNKS_128TB
>> +#define NR_CHUNKS_HIGH  NR_CHUNKS_3968TB
>>   #else
>>   #define HIGH_ADDR_MARK  ADDR_MARK_128TB
>>   #define HIGH_ADDR_SHIFT 48
> Could you also update the comment above this code to say PowerPC64 also
> supports 4PB virtual address space?
>
>  From the comment, arm64 supports 4PB but its NR_CHUNKS_HIGH is only 3840TB,
> whereas PowerPC64 here can get to 3968TB. I do not know why arm64’s
> 4PB is smaller. ;)

The border for high VA space is 128 TB for x86 and ppc, for arm64 it
is 256 TB.

>
> Otherwise, the patch looks good to me.
>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
>
> Best Regards,
> Yan, Zi

Re: [PATCH v2 2/7] selftests/mm: Add support to test 4PB VA on PPC64

[Zi Yan]

On 3 Jul 2025, at 10:44, Dev Jain wrote:

> On 03/07/25 8:11 pm, Zi Yan wrote:
>> On 3 Jul 2025, at 2:06, Aboorva Devarajan wrote:
>>
>>> From: Donet Tom <donettom@linux.ibm.com>
>>>
>>> PowerPC64 supports a 4PB virtual address space, but this test was
>>> previously limited to 512TB. This patch extends the coverage up to
>>> the full 4PB VA range on PowerPC64.
>>>
>>> Memory from 0 to 128TB is allocated without an address hint, while
>>> allocations from 128TB to 4PB use a hint address.
>>>
>>> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
>>> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
>>> ---
>>>   tools/testing/selftests/mm/virtual_address_range.c | 6 ++++++
>>>   1 file changed, 6 insertions(+)
>>>
>>> diff --git a/tools/testing/selftests/mm/virtual_address_range.c b/tools/testing/selftests/mm/virtual_address_range.c
>>> index e24c36a39f22..619acf0b9239 100644
>>> --- a/tools/testing/selftests/mm/virtual_address_range.c
>>> +++ b/tools/testing/selftests/mm/virtual_address_range.c
>>> @@ -50,6 +50,7 @@
>>>   #define NR_CHUNKS_256TB   (NR_CHUNKS_128TB * 2UL)
>>>   #define NR_CHUNKS_384TB   (NR_CHUNKS_128TB * 3UL)
>>>   #define NR_CHUNKS_3840TB  (NR_CHUNKS_128TB * 30UL)
>>> +#define NR_CHUNKS_3968TB  (NR_CHUNKS_128TB * 31UL)
>>>
>>>   #define ADDR_MARK_128TB  (1UL << 47) /* First address beyond 128TB */
>>>   #define ADDR_MARK_256TB  (1UL << 48) /* First address beyond 256TB */
>>> @@ -59,6 +60,11 @@
>>>   #define HIGH_ADDR_SHIFT 49
>>>   #define NR_CHUNKS_LOW   NR_CHUNKS_256TB
>>>   #define NR_CHUNKS_HIGH  NR_CHUNKS_3840TB
>>> +#elif defined(__PPC64__)
>>> +#define HIGH_ADDR_MARK  ADDR_MARK_128TB
>>> +#define HIGH_ADDR_SHIFT 48
>>> +#define NR_CHUNKS_LOW   NR_CHUNKS_128TB
>>> +#define NR_CHUNKS_HIGH  NR_CHUNKS_3968TB
>>>   #else
>>>   #define HIGH_ADDR_MARK  ADDR_MARK_128TB
>>>   #define HIGH_ADDR_SHIFT 48
>> Could you also update the comment above this code to say PowerPC64 also
>> supports 4PB virtual address space?
>>
>>  From the comment, arm64 supports 4PB but its NR_CHUNKS_HIGH is only 3840TB,
>> whereas PowerPC64 here can get to 3968TB. I do not know why arm64’s
>> 4PB is smaller. ;)
>
> The border for high VA space is 128 TB for x86 and ppc, for arm64 it
> is 256 TB.

Thank you for the explanation. :)

Best Regards,
Yan, Zi

Re: [PATCH v2 2/7] selftests/mm: Add support to test 4PB VA on PPC64

[Donet Tom]

On 7/3/25 8:11 PM, Zi Yan wrote:
> On 3 Jul 2025, at 2:06, Aboorva Devarajan wrote:
>
>> From: Donet Tom <donettom@linux.ibm.com>
>>
>> PowerPC64 supports a 4PB virtual address space, but this test was
>> previously limited to 512TB. This patch extends the coverage up to
>> the full 4PB VA range on PowerPC64.
>>
>> Memory from 0 to 128TB is allocated without an address hint, while
>> allocations from 128TB to 4PB use a hint address.
>>
>> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
>> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
>> ---
>>   tools/testing/selftests/mm/virtual_address_range.c | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/tools/testing/selftests/mm/virtual_address_range.c b/tools/testing/selftests/mm/virtual_address_range.c
>> index e24c36a39f22..619acf0b9239 100644
>> --- a/tools/testing/selftests/mm/virtual_address_range.c
>> +++ b/tools/testing/selftests/mm/virtual_address_range.c
>> @@ -50,6 +50,7 @@
>>   #define NR_CHUNKS_256TB   (NR_CHUNKS_128TB * 2UL)
>>   #define NR_CHUNKS_384TB   (NR_CHUNKS_128TB * 3UL)
>>   #define NR_CHUNKS_3840TB  (NR_CHUNKS_128TB * 30UL)
>> +#define NR_CHUNKS_3968TB  (NR_CHUNKS_128TB * 31UL)
>>
>>   #define ADDR_MARK_128TB  (1UL << 47) /* First address beyond 128TB */
>>   #define ADDR_MARK_256TB  (1UL << 48) /* First address beyond 256TB */
>> @@ -59,6 +60,11 @@
>>   #define HIGH_ADDR_SHIFT 49
>>   #define NR_CHUNKS_LOW   NR_CHUNKS_256TB
>>   #define NR_CHUNKS_HIGH  NR_CHUNKS_3840TB
>> +#elif defined(__PPC64__)
>> +#define HIGH_ADDR_MARK  ADDR_MARK_128TB
>> +#define HIGH_ADDR_SHIFT 48
>> +#define NR_CHUNKS_LOW   NR_CHUNKS_128TB
>> +#define NR_CHUNKS_HIGH  NR_CHUNKS_3968TB
>>   #else
>>   #define HIGH_ADDR_MARK  ADDR_MARK_128TB
>>   #define HIGH_ADDR_SHIFT 48
> Could you also update the comment above this code to say PowerPC64 also
> supports 4PB virtual address space?


Sure. I will add


>
>  From the comment, arm64 supports 4PB but its NR_CHUNKS_HIGH is only 3840TB,
> whereas PowerPC64 here can get to 3968TB. I do not know why arm64’s
> 4PB is smaller. ;)
>
> Otherwise, the patch looks good to me.
>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
>
> Best Regards,
> Yan, Zi

[PATCH v2 3/7] selftest/mm: Fix ksm_funtional_test failures

[Aboorva Devarajan]

From: Donet Tom <donettom@linux.ibm.com>

This patch fixed 2 issues.

1)After fork() in test_prctl_fork, the child process uses the file
descriptors from the parent process to read ksm_stat and
ksm_merging_pages. This results in incorrect values being read (parent
process ksm_stat and ksm_merge_pages will be read in child), causing
the test to fail.

This patch calls init_global_file_handles() in the child process to
ensure that the current process's file descriptors are used to read
ksm_stat and ksm_merging_pages.

2) All tests currently call ksm_merge to trigger page merging.
To ensure the system remains in a consistent state for subsequent
tests, it is better to call ksm_unmerge during the test cleanup phase

In the test_prctl_fork test, after a fork(), reading ksm_merging_pages
in the child process returns a non-zero value because a previous test
performed a merge, and the child's memory state is inherited from the
parent.

Although the child process calls ksm_unmerge, the ksm_merging_pages
counter in the parent is reset to zero, while the child's counter
remains unchanged. This discrepancy causes the test to fail.

To avoid this issue, each test should call ksm_unmerge during cleanup
to ensure the counter is reset and the system is in a clean state for
subsequent tests.

execv argument is an array of pointers to null-terminated strings.
In this patch we also added NULL in the execv argument.

Fixes: 6c47de3be3a0 ("selftest/mm: ksm_functional_tests: extend test case for ksm fork/exec")
Signed-off-by: Donet Tom <donettom@linux.ibm.com>
Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
---
 tools/testing/selftests/mm/ksm_functional_tests.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/mm/ksm_functional_tests.c b/tools/testing/selftests/mm/ksm_functional_tests.c
index d8bd1911dfc0..996dc6645570 100644
--- a/tools/testing/selftests/mm/ksm_functional_tests.c
+++ b/tools/testing/selftests/mm/ksm_functional_tests.c
@@ -46,6 +46,8 @@ static int ksm_use_zero_pages_fd;
 static int pagemap_fd;
 static size_t pagesize;
 
+static void init_global_file_handles(void);
+
 static bool range_maps_duplicates(char *addr, unsigned long size)
 {
 	unsigned long offs_a, offs_b, pfn_a, pfn_b;
@@ -274,6 +276,7 @@ static void test_unmerge(void)
 	ksft_test_result(!range_maps_duplicates(map, size),
 			 "Pages were unmerged\n");
 unmap:
+	ksm_unmerge();
 	munmap(map, size);
 }
 
@@ -338,6 +341,7 @@ static void test_unmerge_zero_pages(void)
 	ksft_test_result(!range_maps_duplicates(map, size),
 			"KSM zero pages were unmerged\n");
 unmap:
+	ksm_unmerge();
 	munmap(map, size);
 }
 
@@ -366,6 +370,7 @@ static void test_unmerge_discarded(void)
 	ksft_test_result(!range_maps_duplicates(map, size),
 			 "Pages were unmerged\n");
 unmap:
+	ksm_unmerge();
 	munmap(map, size);
 }
 
@@ -452,6 +457,7 @@ static void test_unmerge_uffd_wp(void)
 close_uffd:
 	close(uffd);
 unmap:
+	ksm_unmerge();
 	munmap(map, size);
 }
 #endif
@@ -515,6 +521,7 @@ static int test_child_ksm(void)
 	else if (map == MAP_MERGE_SKIP)
 		return -3;
 
+	ksm_unmerge();
 	munmap(map, size);
 	return 0;
 }
@@ -548,6 +555,7 @@ static void test_prctl_fork(void)
 
 	child_pid = fork();
 	if (!child_pid) {
+		init_global_file_handles();
 		exit(test_child_ksm());
 	} else if (child_pid < 0) {
 		ksft_test_result_fail("fork() failed\n");
@@ -595,7 +603,7 @@ static void test_prctl_fork_exec(void)
 		return;
 	} else if (child_pid == 0) {
 		char *prg_name = "./ksm_functional_tests";
-		char *argv_for_program[] = { prg_name, FORK_EXEC_CHILD_PRG_NAME };
+		char *argv_for_program[] = { prg_name, FORK_EXEC_CHILD_PRG_NAME, NULL };
 
 		execv(prg_name, argv_for_program);
 		return;
@@ -644,6 +652,7 @@ static void test_prctl_unmerge(void)
 	ksft_test_result(!range_maps_duplicates(map, size),
 			 "Pages were unmerged\n");
 unmap:
+	ksm_unmerge();
 	munmap(map, size);
 }
 
@@ -677,6 +686,7 @@ static void test_prot_none(void)
 	ksft_test_result(!range_maps_duplicates(map, size),
 			 "Pages were unmerged\n");
 unmap:
+	ksm_unmerge();
 	munmap(map, size);
 }
 
-- 
2.43.5

[PATCH v2 4/7] mm/selftests: Fix split_huge_page_test failure on systems with 64KB page size

[Aboorva Devarajan]

From: Donet Tom <donettom@linux.ibm.com>

The split_huge_page_test fails on systems with a 64KB base page size.
This is because the order of a 2MB huge page is different:

On 64KB systems, the order is 5.

On 4KB systems, it's 9.

The test currently assumes a maximum huge page order of 9, which is only
valid for 4KB base page systems. On systems with 64KB pages, attempting
to split huge pages beyond their actual order (5) causes the test to fail.

In this patch, we calculate the huge page order based on the system's base
page size. With this change, the tests now run successfully on both 64KB
and 4KB page size systems.

Fixes: fa6c02315f745 ("mm: huge_memory: a new debugfs interface for splitting THP tests")
Signed-off-by: Donet Tom <donettom@linux.ibm.com>
Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
---
 .../selftests/mm/split_huge_page_test.c       | 23 ++++++++++++++-----
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/tools/testing/selftests/mm/split_huge_page_test.c b/tools/testing/selftests/mm/split_huge_page_test.c
index aa7400ed0e99..38296a758330 100644
--- a/tools/testing/selftests/mm/split_huge_page_test.c
+++ b/tools/testing/selftests/mm/split_huge_page_test.c
@@ -514,6 +514,15 @@ void split_thp_in_pagecache_to_order_at(size_t fd_size, const char *fs_loc,
 	}
 }
 
+static unsigned int get_order(unsigned int pages)
+{
+	unsigned int order = 0;
+
+	while ((1U << order) < pages)
+		order++;
+	return order;
+}
+
 int main(int argc, char **argv)
 {
 	int i;
@@ -523,6 +532,7 @@ int main(int argc, char **argv)
 	const char *fs_loc;
 	bool created_tmp;
 	int offset;
+	unsigned int max_order;
 
 	ksft_print_header();
 
@@ -534,32 +544,33 @@ int main(int argc, char **argv)
 	if (argc > 1)
 		optional_xfs_path = argv[1];
 
-	ksft_set_plan(1+8+1+9+9+8*4+2);
-
 	pagesize = getpagesize();
 	pageshift = ffs(pagesize) - 1;
 	pmd_pagesize = read_pmd_pagesize();
 	if (!pmd_pagesize)
 		ksft_exit_fail_msg("Reading PMD pagesize failed\n");
 
+	max_order = get_order(pmd_pagesize/pagesize);
+	ksft_set_plan(1+(max_order-1)+1+max_order+max_order+(max_order-1)*4+2);
+
 	fd_size = 2 * pmd_pagesize;
 
 	split_pmd_zero_pages();
 
-	for (i = 0; i < 9; i++)
+	for (i = 0; i < max_order; i++)
 		if (i != 1)
 			split_pmd_thp_to_order(i);
 
 	split_pte_mapped_thp();
-	for (i = 0; i < 9; i++)
+	for (i = 0; i < max_order; i++)
 		split_file_backed_thp(i);
 
 	created_tmp = prepare_thp_fs(optional_xfs_path, fs_loc_template,
 			&fs_loc);
-	for (i = 8; i >= 0; i--)
+	for (i = (max_order-1); i >= 0; i--)
 		split_thp_in_pagecache_to_order_at(fd_size, fs_loc, i, -1);
 
-	for (i = 0; i < 9; i++)
+	for (i = 0; i < max_order; i++)
 		for (offset = 0;
 		     offset < pmd_pagesize / pagesize;
 		     offset += MAX(pmd_pagesize / pagesize / 4, 1 << i))
-- 
2.43.5

Re: [PATCH v2 4/7] mm/selftests: Fix split_huge_page_test failure on systems with 64KB page size

[Dev Jain]

On 03/07/25 11:36 am, Aboorva Devarajan wrote:
> From: Donet Tom <donettom@linux.ibm.com>
>
> The split_huge_page_test fails on systems with a 64KB base page size.
> This is because the order of a 2MB huge page is different:
>
> On 64KB systems, the order is 5.
>
> On 4KB systems, it's 9.
>
> The test currently assumes a maximum huge page order of 9, which is only
> valid for 4KB base page systems. On systems with 64KB pages, attempting
> to split huge pages beyond their actual order (5) causes the test to fail.
>
> In this patch, we calculate the huge page order based on the system's base
> page size. With this change, the tests now run successfully on both 64KB
> and 4KB page size systems.
>
> Fixes: fa6c02315f745 ("mm: huge_memory: a new debugfs interface for splitting THP tests")
> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
> ---
>   

LGTM

Reviewed-by: Dev Jain <dev.jain@arm.com>

Re: [PATCH v2 4/7] mm/selftests: Fix split_huge_page_test failure on systems with 64KB page size

[David Hildenbrand]

On 03.07.25 08:06, Aboorva Devarajan wrote:
> From: Donet Tom <donettom@linux.ibm.com>
> 
> The split_huge_page_test fails on systems with a 64KB base page size.
> This is because the order of a 2MB huge page is different:
> 
> On 64KB systems, the order is 5.
> 
> On 4KB systems, it's 9.
> 
> The test currently assumes a maximum huge page order of 9, which is only
> valid for 4KB base page systems. On systems with 64KB pages, attempting
> to split huge pages beyond their actual order (5) causes the test to fail.
> 
> In this patch, we calculate the huge page order based on the system's base
> page size. With this change, the tests now run successfully on both 64KB
> and 4KB page size systems.
> 
> Fixes: fa6c02315f745 ("mm: huge_memory: a new debugfs interface for splitting THP tests")
> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
> ---
>   .../selftests/mm/split_huge_page_test.c       | 23 ++++++++++++++-----
>   1 file changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/testing/selftests/mm/split_huge_page_test.c b/tools/testing/selftests/mm/split_huge_page_test.c
> index aa7400ed0e99..38296a758330 100644
> --- a/tools/testing/selftests/mm/split_huge_page_test.c
> +++ b/tools/testing/selftests/mm/split_huge_page_test.c
> @@ -514,6 +514,15 @@ void split_thp_in_pagecache_to_order_at(size_t fd_size, const char *fs_loc,
>   	}
>   }
>   
> +static unsigned int get_order(unsigned int pages)
> +{
> +	unsigned int order = 0;
> +
> +	while ((1U << order) < pages)
> +		order++;
> +	return order;
> +}

I think this can simply be

return 32 - __builtin_clz(pages - 1);

That mimics what get_order() in the kernel does for BITS_PER_LONG == 32

or simpler

return 31 - __builtin_clz(pages);

E.g., if pages=512, you get 31-22=9

> +
>   int main(int argc, char **argv)
>   {
>   	int i;
> @@ -523,6 +532,7 @@ int main(int argc, char **argv)
>   	const char *fs_loc;
>   	bool created_tmp;
>   	int offset;
> +	unsigned int max_order;
>   
>   	ksft_print_header();
>   
> @@ -534,32 +544,33 @@ int main(int argc, char **argv)
>   	if (argc > 1)
>   		optional_xfs_path = argv[1];
>   
> -	ksft_set_plan(1+8+1+9+9+8*4+2);
> -
>   	pagesize = getpagesize();
>   	pageshift = ffs(pagesize) - 1;
>   	pmd_pagesize = read_pmd_pagesize();
>   	if (!pmd_pagesize)
>   		ksft_exit_fail_msg("Reading PMD pagesize failed\n");
>   
> +	max_order = get_order(pmd_pagesize/pagesize);
> +	ksft_set_plan(1+(max_order-1)+1+max_order+max_order+(max_order-1)*4+2);

Wow. Can we simplify that in any sane way?

> +
>   	fd_size = 2 * pmd_pagesize;
>   
>   	split_pmd_zero_pages();
>   
> -	for (i = 0; i < 9; i++)
> +	for (i = 0; i < max_order; i++)
>   		if (i != 1)
>   			split_pmd_thp_to_order(i);
>   
>   	split_pte_mapped_thp();
> -	for (i = 0; i < 9; i++)
> +	for (i = 0; i < max_order; i++)
>   		split_file_backed_thp(i);
>   
>   	created_tmp = prepare_thp_fs(optional_xfs_path, fs_loc_template,
>   			&fs_loc);
> -	for (i = 8; i >= 0; i--)
> +	for (i = (max_order-1); i >= 0; i--)

"i = max_order - 1"

>   		split_thp_in_pagecache_to_order_at(fd_size, fs_loc, i, -1);
>   
> -	for (i = 0; i < 9; i++)
> +	for (i = 0; i < max_order; i++)
>   		for (offset = 0;
>   		     offset < pmd_pagesize / pagesize;
>   		     offset += MAX(pmd_pagesize / pagesize / 4, 1 << i))


-- 
Cheers,

David / dhildenb

Re: [PATCH v2 4/7] mm/selftests: Fix split_huge_page_test failure on systems with 64KB page size

[Donet Tom]

On 7/3/25 1:52 PM, David Hildenbrand wrote:
> On 03.07.25 08:06, Aboorva Devarajan wrote:
>> From: Donet Tom <donettom@linux.ibm.com>
>>
>> The split_huge_page_test fails on systems with a 64KB base page size.
>> This is because the order of a 2MB huge page is different:
>>
>> On 64KB systems, the order is 5.
>>
>> On 4KB systems, it's 9.
>>
>> The test currently assumes a maximum huge page order of 9, which is only
>> valid for 4KB base page systems. On systems with 64KB pages, attempting
>> to split huge pages beyond their actual order (5) causes the test to 
>> fail.
>>
>> In this patch, we calculate the huge page order based on the system's 
>> base
>> page size. With this change, the tests now run successfully on both 64KB
>> and 4KB page size systems.
>>
>> Fixes: fa6c02315f745 ("mm: huge_memory: a new debugfs interface for 
>> splitting THP tests")
>> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
>> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
>> ---
>>   .../selftests/mm/split_huge_page_test.c       | 23 ++++++++++++++-----
>>   1 file changed, 17 insertions(+), 6 deletions(-)
>>
>> diff --git a/tools/testing/selftests/mm/split_huge_page_test.c 
>> b/tools/testing/selftests/mm/split_huge_page_test.c
>> index aa7400ed0e99..38296a758330 100644
>> --- a/tools/testing/selftests/mm/split_huge_page_test.c
>> +++ b/tools/testing/selftests/mm/split_huge_page_test.c
>> @@ -514,6 +514,15 @@ void split_thp_in_pagecache_to_order_at(size_t 
>> fd_size, const char *fs_loc,
>>       }
>>   }
>>   +static unsigned int get_order(unsigned int pages)
>> +{
>> +    unsigned int order = 0;
>> +
>> +    while ((1U << order) < pages)
>> +        order++;
>> +    return order;
>> +}
>
> I think this can simply be
>
> return 32 - __builtin_clz(pages - 1);
>
> That mimics what get_order() in the kernel does for BITS_PER_LONG == 32
>
> or simpler
>
> return 31 - __builtin_clz(pages);
>
> E.g., if pages=512, you get 31-22=9


Sure David, We will  change it.


>
>> +
>>   int main(int argc, char **argv)
>>   {
>>       int i;
>> @@ -523,6 +532,7 @@ int main(int argc, char **argv)
>>       const char *fs_loc;
>>       bool created_tmp;
>>       int offset;
>> +    unsigned int max_order;
>>         ksft_print_header();
>>   @@ -534,32 +544,33 @@ int main(int argc, char **argv)
>>       if (argc > 1)
>>           optional_xfs_path = argv[1];
>>   -    ksft_set_plan(1+8+1+9+9+8*4+2);
>> -
>>       pagesize = getpagesize();
>>       pageshift = ffs(pagesize) - 1;
>>       pmd_pagesize = read_pmd_pagesize();
>>       if (!pmd_pagesize)
>>           ksft_exit_fail_msg("Reading PMD pagesize failed\n");
>>   +    max_order = get_order(pmd_pagesize/pagesize);
>> + 
>> ksft_set_plan(1+(max_order-1)+1+max_order+max_order+(max_order-1)*4+2);
>
> Wow. Can we simplify that in any sane way?


It is counting test by test. Let me try to simplify it and send the next 
version.


>
>> +
>>       fd_size = 2 * pmd_pagesize;
>>         split_pmd_zero_pages();
>>   -    for (i = 0; i < 9; i++)
>> +    for (i = 0; i < max_order; i++)
>>           if (i != 1)
>>               split_pmd_thp_to_order(i);
>>         split_pte_mapped_thp();
>> -    for (i = 0; i < 9; i++)
>> +    for (i = 0; i < max_order; i++)
>>           split_file_backed_thp(i);
>>         created_tmp = prepare_thp_fs(optional_xfs_path, fs_loc_template,
>>               &fs_loc);
>> -    for (i = 8; i >= 0; i--)
>> +    for (i = (max_order-1); i >= 0; i--)
>
> "i = max_order - 1"


I will change it.


>
>> split_thp_in_pagecache_to_order_at(fd_size, fs_loc, i, -1);
>>   -    for (i = 0; i < 9; i++)
>> +    for (i = 0; i < max_order; i++)
>>           for (offset = 0;
>>                offset < pmd_pagesize / pagesize;
>>                offset += MAX(pmd_pagesize / pagesize / 4, 1 << i))
>
>

Re: [PATCH v2 4/7] mm/selftests: Fix split_huge_page_test failure on systems with 64KB page size

[Zi Yan]

On 3 Jul 2025, at 4:58, Donet Tom wrote:

> On 7/3/25 1:52 PM, David Hildenbrand wrote:
>> On 03.07.25 08:06, Aboorva Devarajan wrote:
>>> From: Donet Tom <donettom@linux.ibm.com>
>>>
>>> The split_huge_page_test fails on systems with a 64KB base page size.
>>> This is because the order of a 2MB huge page is different:
>>>
>>> On 64KB systems, the order is 5.
>>>
>>> On 4KB systems, it's 9.
>>>
>>> The test currently assumes a maximum huge page order of 9, which is only
>>> valid for 4KB base page systems. On systems with 64KB pages, attempting
>>> to split huge pages beyond their actual order (5) causes the test to fail.
>>>
>>> In this patch, we calculate the huge page order based on the system's base
>>> page size. With this change, the tests now run successfully on both 64KB
>>> and 4KB page size systems.
>>>
>>> Fixes: fa6c02315f745 ("mm: huge_memory: a new debugfs interface for splitting THP tests")
>>> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
>>> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
>>> ---
>>>   .../selftests/mm/split_huge_page_test.c       | 23 ++++++++++++++-----
>>>   1 file changed, 17 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/tools/testing/selftests/mm/split_huge_page_test.c b/tools/testing/selftests/mm/split_huge_page_test.c
>>> index aa7400ed0e99..38296a758330 100644
>>> --- a/tools/testing/selftests/mm/split_huge_page_test.c
>>> +++ b/tools/testing/selftests/mm/split_huge_page_test.c
>>> @@ -514,6 +514,15 @@ void split_thp_in_pagecache_to_order_at(size_t fd_size, const char *fs_loc,
>>>       }
>>>   }
>>>   +static unsigned int get_order(unsigned int pages)
>>> +{
>>> +    unsigned int order = 0;
>>> +
>>> +    while ((1U << order) < pages)
>>> +        order++;
>>> +    return order;
>>> +}
>>
>> I think this can simply be
>>
>> return 32 - __builtin_clz(pages - 1);
>>
>> That mimics what get_order() in the kernel does for BITS_PER_LONG == 32
>>
>> or simpler
>>
>> return 31 - __builtin_clz(pages);
>>
>> E.g., if pages=512, you get 31-22=9
>
>
> Sure David, We will  change it.
>
>
>>
>>> +
>>>   int main(int argc, char **argv)
>>>   {
>>>       int i;
>>> @@ -523,6 +532,7 @@ int main(int argc, char **argv)
>>>       const char *fs_loc;
>>>       bool created_tmp;
>>>       int offset;
>>> +    unsigned int max_order;
>>>         ksft_print_header();
>>>   @@ -534,32 +544,33 @@ int main(int argc, char **argv)
>>>       if (argc > 1)
>>>           optional_xfs_path = argv[1];
>>>   -    ksft_set_plan(1+8+1+9+9+8*4+2);
>>> -
>>>       pagesize = getpagesize();
>>>       pageshift = ffs(pagesize) - 1;
>>>       pmd_pagesize = read_pmd_pagesize();
>>>       if (!pmd_pagesize)
>>>           ksft_exit_fail_msg("Reading PMD pagesize failed\n");
>>>   +    max_order = get_order(pmd_pagesize/pagesize);
>>> + ksft_set_plan(1+(max_order-1)+1+max_order+max_order+(max_order-1)*4+2);
>>
>> Wow. Can we simplify that in any sane way?
>
>
> It is counting test by test. Let me try to simplify it and send the next version.

Yeah, I did that (ksft_set_plan(1+8+1+9+9+8*4+2);) to count different tests
separately and in the same order as the following tests, so that I could
get ksft_set_plan number right when adding or removing tests. Maybe it is
fine to just sum them up now.

Best Regards,
Yan, Zi

Re: [PATCH v2 4/7] mm/selftests: Fix split_huge_page_test failure on systems with 64KB page size

[Donet Tom]

On 7/3/25 7:51 PM, Zi Yan wrote:
> On 3 Jul 2025, at 4:58, Donet Tom wrote:
>
>> On 7/3/25 1:52 PM, David Hildenbrand wrote:
>>> On 03.07.25 08:06, Aboorva Devarajan wrote:
>>>> From: Donet Tom <donettom@linux.ibm.com>
>>>>
>>>> The split_huge_page_test fails on systems with a 64KB base page size.
>>>> This is because the order of a 2MB huge page is different:
>>>>
>>>> On 64KB systems, the order is 5.
>>>>
>>>> On 4KB systems, it's 9.
>>>>
>>>> The test currently assumes a maximum huge page order of 9, which is only
>>>> valid for 4KB base page systems. On systems with 64KB pages, attempting
>>>> to split huge pages beyond their actual order (5) causes the test to fail.
>>>>
>>>> In this patch, we calculate the huge page order based on the system's base
>>>> page size. With this change, the tests now run successfully on both 64KB
>>>> and 4KB page size systems.
>>>>
>>>> Fixes: fa6c02315f745 ("mm: huge_memory: a new debugfs interface for splitting THP tests")
>>>> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
>>>> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
>>>> ---
>>>>    .../selftests/mm/split_huge_page_test.c       | 23 ++++++++++++++-----
>>>>    1 file changed, 17 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/tools/testing/selftests/mm/split_huge_page_test.c b/tools/testing/selftests/mm/split_huge_page_test.c
>>>> index aa7400ed0e99..38296a758330 100644
>>>> --- a/tools/testing/selftests/mm/split_huge_page_test.c
>>>> +++ b/tools/testing/selftests/mm/split_huge_page_test.c
>>>> @@ -514,6 +514,15 @@ void split_thp_in_pagecache_to_order_at(size_t fd_size, const char *fs_loc,
>>>>        }
>>>>    }
>>>>    +static unsigned int get_order(unsigned int pages)
>>>> +{
>>>> +    unsigned int order = 0;
>>>> +
>>>> +    while ((1U << order) < pages)
>>>> +        order++;
>>>> +    return order;
>>>> +}
>>> I think this can simply be
>>>
>>> return 32 - __builtin_clz(pages - 1);
>>>
>>> That mimics what get_order() in the kernel does for BITS_PER_LONG == 32
>>>
>>> or simpler
>>>
>>> return 31 - __builtin_clz(pages);
>>>
>>> E.g., if pages=512, you get 31-22=9
>>
>> Sure David, We will  change it.
>>
>>
>>>> +
>>>>    int main(int argc, char **argv)
>>>>    {
>>>>        int i;
>>>> @@ -523,6 +532,7 @@ int main(int argc, char **argv)
>>>>        const char *fs_loc;
>>>>        bool created_tmp;
>>>>        int offset;
>>>> +    unsigned int max_order;
>>>>          ksft_print_header();
>>>>    @@ -534,32 +544,33 @@ int main(int argc, char **argv)
>>>>        if (argc > 1)
>>>>            optional_xfs_path = argv[1];
>>>>    -    ksft_set_plan(1+8+1+9+9+8*4+2);
>>>> -
>>>>        pagesize = getpagesize();
>>>>        pageshift = ffs(pagesize) - 1;
>>>>        pmd_pagesize = read_pmd_pagesize();
>>>>        if (!pmd_pagesize)
>>>>            ksft_exit_fail_msg("Reading PMD pagesize failed\n");
>>>>    +    max_order = get_order(pmd_pagesize/pagesize);
>>>> + ksft_set_plan(1+(max_order-1)+1+max_order+max_order+(max_order-1)*4+2);
>>> Wow. Can we simplify that in any sane way?
>>
>> It is counting test by test. Let me try to simplify it and send the next version.
> Yeah, I did that (ksft_set_plan(1+8+1+9+9+8*4+2);) to count different tests
> separately and in the same order as the following tests, so that I could
> get ksft_set_plan number right when adding or removing tests. Maybe it is
> fine to just sum them up now.


Sure. Thank you


>
> Best Regards,
> Yan, Zi
>

Re: [PATCH v2 4/7] mm/selftests: Fix split_huge_page_test failure on systems with 64KB page size

[Zi Yan]

On 3 Jul 2025, at 2:06, Aboorva Devarajan wrote:

> From: Donet Tom <donettom@linux.ibm.com>
>
> The split_huge_page_test fails on systems with a 64KB base page size.
> This is because the order of a 2MB huge page is different:
>
> On 64KB systems, the order is 5.
>
> On 4KB systems, it's 9.
>
> The test currently assumes a maximum huge page order of 9, which is only
> valid for 4KB base page systems. On systems with 64KB pages, attempting
> to split huge pages beyond their actual order (5) causes the test to fail.
>
> In this patch, we calculate the huge page order based on the system's base
> page size. With this change, the tests now run successfully on both 64KB
> and 4KB page size systems.
>
> Fixes: fa6c02315f745 ("mm: huge_memory: a new debugfs interface for splitting THP tests")
> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
> ---
>  .../selftests/mm/split_huge_page_test.c       | 23 ++++++++++++++-----
>  1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/tools/testing/selftests/mm/split_huge_page_test.c b/tools/testing/selftests/mm/split_huge_page_test.c
> index aa7400ed0e99..38296a758330 100644
> --- a/tools/testing/selftests/mm/split_huge_page_test.c
> +++ b/tools/testing/selftests/mm/split_huge_page_test.c
> @@ -514,6 +514,15 @@ void split_thp_in_pagecache_to_order_at(size_t fd_size, const char *fs_loc,
>  	}
>  }
>
> +static unsigned int get_order(unsigned int pages)
> +{
> +	unsigned int order = 0;
> +
> +	while ((1U << order) < pages)
> +		order++;
> +	return order;
> +}
> +
>  int main(int argc, char **argv)
>  {
>  	int i;
> @@ -523,6 +532,7 @@ int main(int argc, char **argv)
>  	const char *fs_loc;
>  	bool created_tmp;
>  	int offset;
> +	unsigned int max_order;
>
>  	ksft_print_header();
>
> @@ -534,32 +544,33 @@ int main(int argc, char **argv)
>  	if (argc > 1)
>  		optional_xfs_path = argv[1];
>
> -	ksft_set_plan(1+8+1+9+9+8*4+2);
> -
>  	pagesize = getpagesize();
>  	pageshift = ffs(pagesize) - 1;
>  	pmd_pagesize = read_pmd_pagesize();
>  	if (!pmd_pagesize)
>  		ksft_exit_fail_msg("Reading PMD pagesize failed\n");
>
> +	max_order = get_order(pmd_pagesize/pagesize);

pmd_pagesize/pagesize is reused below, a tmp variable would be good.

> +	ksft_set_plan(1+(max_order-1)+1+max_order+max_order+(max_order-1)*4+2);
> +
>  	fd_size = 2 * pmd_pagesize;
>
>  	split_pmd_zero_pages();
>
> -	for (i = 0; i < 9; i++)
> +	for (i = 0; i < max_order; i++)
>  		if (i != 1)
>  			split_pmd_thp_to_order(i);
>
>  	split_pte_mapped_thp();
> -	for (i = 0; i < 9; i++)
> +	for (i = 0; i < max_order; i++)
>  		split_file_backed_thp(i);
>
>  	created_tmp = prepare_thp_fs(optional_xfs_path, fs_loc_template,
>  			&fs_loc);
> -	for (i = 8; i >= 0; i--)
> +	for (i = (max_order-1); i >= 0; i--)
>  		split_thp_in_pagecache_to_order_at(fd_size, fs_loc, i, -1);
>
> -	for (i = 0; i < 9; i++)
> +	for (i = 0; i < max_order; i++)
>  		for (offset = 0;
>  		     offset < pmd_pagesize / pagesize;
>  		     offset += MAX(pmd_pagesize / pagesize / 4, 1 << i))

With the change to get_order() proposed by David and ksft_set_plan()
simplification, Reviewed-by: Zi Yan <ziy@nvidia.com>

Best Regards,
Yan, Zi

Re: [PATCH v2 4/7] mm/selftests: Fix split_huge_page_test failure on systems with 64KB page size

[Donet Tom]

On 7/3/25 8:00 PM, Zi Yan wrote:
> On 3 Jul 2025, at 2:06, Aboorva Devarajan wrote:
>
>> From: Donet Tom <donettom@linux.ibm.com>
>>
>> The split_huge_page_test fails on systems with a 64KB base page size.
>> This is because the order of a 2MB huge page is different:
>>
>> On 64KB systems, the order is 5.
>>
>> On 4KB systems, it's 9.
>>
>> The test currently assumes a maximum huge page order of 9, which is only
>> valid for 4KB base page systems. On systems with 64KB pages, attempting
>> to split huge pages beyond their actual order (5) causes the test to fail.
>>
>> In this patch, we calculate the huge page order based on the system's base
>> page size. With this change, the tests now run successfully on both 64KB
>> and 4KB page size systems.
>>
>> Fixes: fa6c02315f745 ("mm: huge_memory: a new debugfs interface for splitting THP tests")
>> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
>> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
>> ---
>>   .../selftests/mm/split_huge_page_test.c       | 23 ++++++++++++++-----
>>   1 file changed, 17 insertions(+), 6 deletions(-)
>>
>> diff --git a/tools/testing/selftests/mm/split_huge_page_test.c b/tools/testing/selftests/mm/split_huge_page_test.c
>> index aa7400ed0e99..38296a758330 100644
>> --- a/tools/testing/selftests/mm/split_huge_page_test.c
>> +++ b/tools/testing/selftests/mm/split_huge_page_test.c
>> @@ -514,6 +514,15 @@ void split_thp_in_pagecache_to_order_at(size_t fd_size, const char *fs_loc,
>>   	}
>>   }
>>
>> +static unsigned int get_order(unsigned int pages)
>> +{
>> +	unsigned int order = 0;
>> +
>> +	while ((1U << order) < pages)
>> +		order++;
>> +	return order;
>> +}
>> +
>>   int main(int argc, char **argv)
>>   {
>>   	int i;
>> @@ -523,6 +532,7 @@ int main(int argc, char **argv)
>>   	const char *fs_loc;
>>   	bool created_tmp;
>>   	int offset;
>> +	unsigned int max_order;
>>
>>   	ksft_print_header();
>>
>> @@ -534,32 +544,33 @@ int main(int argc, char **argv)
>>   	if (argc > 1)
>>   		optional_xfs_path = argv[1];
>>
>> -	ksft_set_plan(1+8+1+9+9+8*4+2);
>> -
>>   	pagesize = getpagesize();
>>   	pageshift = ffs(pagesize) - 1;
>>   	pmd_pagesize = read_pmd_pagesize();
>>   	if (!pmd_pagesize)
>>   		ksft_exit_fail_msg("Reading PMD pagesize failed\n");
>>
>> +	max_order = get_order(pmd_pagesize/pagesize);
> pmd_pagesize/pagesize is reused below, a tmp variable would be good.


Thank you. I will add it in next version.


>
>> +	ksft_set_plan(1+(max_order-1)+1+max_order+max_order+(max_order-1)*4+2);
>> +
>>   	fd_size = 2 * pmd_pagesize;
>>
>>   	split_pmd_zero_pages();
>>
>> -	for (i = 0; i < 9; i++)
>> +	for (i = 0; i < max_order; i++)
>>   		if (i != 1)
>>   			split_pmd_thp_to_order(i);
>>
>>   	split_pte_mapped_thp();
>> -	for (i = 0; i < 9; i++)
>> +	for (i = 0; i < max_order; i++)
>>   		split_file_backed_thp(i);
>>
>>   	created_tmp = prepare_thp_fs(optional_xfs_path, fs_loc_template,
>>   			&fs_loc);
>> -	for (i = 8; i >= 0; i--)
>> +	for (i = (max_order-1); i >= 0; i--)
>>   		split_thp_in_pagecache_to_order_at(fd_size, fs_loc, i, -1);
>>
>> -	for (i = 0; i < 9; i++)
>> +	for (i = 0; i < max_order; i++)
>>   		for (offset = 0;
>>   		     offset < pmd_pagesize / pagesize;
>>   		     offset += MAX(pmd_pagesize / pagesize / 4, 1 << i))
> With the change to get_order() proposed by David and ksft_set_plan()
> simplification, Reviewed-by: Zi Yan <ziy@nvidia.com>
>
> Best Regards,
> Yan, Zi

[PATCH v2 5/7] selftests/mm: Fix child process exit codes in ksm_functional_tests

[Aboorva Devarajan]

In ksm_functional_tests, test_child_ksm() returned negative values
to indicate errors. However, when passed to exit(), these were
interpreted as large unsigned values (e.g, -2 became 254), leading to
incorrect handling in the parent process. As a result, some tests
appeared to be skipped or silently failed.

This patch changes test_child_ksm() to return positive error codes
(1, 2, 3) and updates test_child_ksm_err() to interpret them correctly.
This ensures the parent accurately detects and reports child process
failures.

--------------
Before patch:
--------------
- [RUN] test_unmerge
ok 1 Pages were unmerged
...
- [RUN] test_prctl_fork
- No pages got merged
- [RUN] test_prctl_fork_exec
ok 7 PR_SET_MEMORY_MERGE value is inherited
...
Bail out! 1 out of 8 tests failed
- Planned tests != run tests (9 != 8)
- Totals: pass:7 fail:1 xfail:0 xpass:0 skip:0 error:0

--------------
After patch:
--------------
- [RUN] test_unmerge
ok 1 Pages were unmerged
...
- [RUN] test_prctl_fork
- No pages got merged
not ok 7 Merge in child failed
- [RUN] test_prctl_fork_exec
ok 8 PR_SET_MEMORY_MERGE value is inherited
...
Bail out! 2 out of 9 tests failed
- Totals: pass:7 fail:2 xfail:0 xpass:0 skip:0 error:0

Fixes: 6c47de3be3a0 ("selftest/mm: ksm_functional_tests: extend test case for ksm fork/exec")
Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
---
 tools/testing/selftests/mm/ksm_functional_tests.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/tools/testing/selftests/mm/ksm_functional_tests.c b/tools/testing/selftests/mm/ksm_functional_tests.c
index 996dc6645570..b080d591d984 100644
--- a/tools/testing/selftests/mm/ksm_functional_tests.c
+++ b/tools/testing/selftests/mm/ksm_functional_tests.c
@@ -512,14 +512,14 @@ static int test_child_ksm(void)
 
 	/* Test if KSM is enabled for the process. */
 	if (prctl(PR_GET_MEMORY_MERGE, 0, 0, 0, 0) != 1)
-		return -1;
+		return 1;
 
 	/* Test if merge could really happen. */
 	map = __mmap_and_merge_range(0xcf, size, PROT_READ | PROT_WRITE, KSM_MERGE_NONE);
 	if (map == MAP_MERGE_FAIL)
-		return -2;
+		return 2;
 	else if (map == MAP_MERGE_SKIP)
-		return -3;
+		return 3;
 
 	ksm_unmerge();
 	munmap(map, size);
@@ -528,11 +528,11 @@ static int test_child_ksm(void)
 
 static void test_child_ksm_err(int status)
 {
-	if (status == -1)
+	if (status == 1)
 		ksft_test_result_fail("unexpected PR_GET_MEMORY_MERGE result in child\n");
-	else if (status == -2)
+	else if (status == 2)
 		ksft_test_result_fail("Merge in child failed\n");
-	else if (status == -3)
+	else if (status == 3)
 		ksft_test_result_skip("Merge in child skipped\n");
 }
 
-- 
2.43.5

Re: [PATCH v2 5/7] selftests/mm: Fix child process exit codes in ksm_functional_tests

[David Hildenbrand]

On 03.07.25 08:06, Aboorva Devarajan wrote:
> In ksm_functional_tests, test_child_ksm() returned negative values
> to indicate errors. However, when passed to exit(), these were
> interpreted as large unsigned values (e.g, -2 became 254), leading to
> incorrect handling in the parent process. As a result, some tests
> appeared to be skipped or silently failed.
> 
> This patch changes test_child_ksm() to return positive error codes
> (1, 2, 3) and updates test_child_ksm_err() to interpret them correctly.
> This ensures the parent accurately detects and reports child process
> failures.
> 
> --------------
> Before patch:
> --------------
> - [RUN] test_unmerge
> ok 1 Pages were unmerged
> ...
> - [RUN] test_prctl_fork
> - No pages got merged
> - [RUN] test_prctl_fork_exec
> ok 7 PR_SET_MEMORY_MERGE value is inherited
> ...
> Bail out! 1 out of 8 tests failed
> - Planned tests != run tests (9 != 8)
> - Totals: pass:7 fail:1 xfail:0 xpass:0 skip:0 error:0
> 
> --------------
> After patch:
> --------------
> - [RUN] test_unmerge
> ok 1 Pages were unmerged
> ...
> - [RUN] test_prctl_fork
> - No pages got merged
> not ok 7 Merge in child failed
> - [RUN] test_prctl_fork_exec
> ok 8 PR_SET_MEMORY_MERGE value is inherited
> ...
> Bail out! 2 out of 9 tests failed
> - Totals: pass:7 fail:2 xfail:0 xpass:0 skip:0 error:0
> 
> Fixes: 6c47de3be3a0 ("selftest/mm: ksm_functional_tests: extend test case for ksm fork/exec")
> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>

Surprising, but seems to be the right thing to do.

Acked-by: David Hildenbrand <david@redhat.com>

-- 
Cheers,

David / dhildenb

Re: [PATCH v2 5/7] selftests/mm: Fix child process exit codes in ksm_functional_tests

[David Hildenbrand]

On 03.07.25 08:06, Aboorva Devarajan wrote:
> In ksm_functional_tests, test_child_ksm() returned negative values
> to indicate errors. However, when passed to exit(), these were
> interpreted as large unsigned values (e.g, -2 became 254), leading to
> incorrect handling in the parent process. As a result, some tests
> appeared to be skipped or silently failed.
> 
> This patch changes test_child_ksm() to return positive error codes
> (1, 2, 3) and updates test_child_ksm_err() to interpret them correctly.
> This ensures the parent accurately detects and reports child process
> failures.
> 
> --------------
> Before patch:
> --------------
> - [RUN] test_unmerge
> ok 1 Pages were unmerged
> ...
> - [RUN] test_prctl_fork
> - No pages got merged
> - [RUN] test_prctl_fork_exec
> ok 7 PR_SET_MEMORY_MERGE value is inherited
> ...
> Bail out! 1 out of 8 tests failed
> - Planned tests != run tests (9 != 8)
> - Totals: pass:7 fail:1 xfail:0 xpass:0 skip:0 error:0
> 
> --------------
> After patch:
> --------------
> - [RUN] test_unmerge
> ok 1 Pages were unmerged
> ...
> - [RUN] test_prctl_fork
> - No pages got merged
> not ok 7 Merge in child failed
> - [RUN] test_prctl_fork_exec
> ok 8 PR_SET_MEMORY_MERGE value is inherited
> ...
> Bail out! 2 out of 9 tests failed
> - Totals: pass:7 fail:2 xfail:0 xpass:0 skip:0 error:0
> 
> Fixes: 6c47de3be3a0 ("selftest/mm: ksm_functional_tests: extend test case for ksm fork/exec")
> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>

BTW, when I run the test, I get this weird output

TAP version 13
1..9
# [RUN] test_unmerge
ok 1 Pages were unmerged
# [RUN] test_unmerge_zero_pages
ok 2 KSM zero pages were unmerged
# [RUN] test_unmerge_discarded
ok 3 Pages were unmerged
# [RUN] test_unmerge_uffd_wp
ok 4 Pages were unmerged
# [RUN] test_prot_none
ok 5 Pages were unmerged
# [RUN] test_prctl
ok 6 Setting/clearing PR_SET_MEMORY_MERGE works
# [RUN] test_prctl_fork
ok 7 PR_SET_MEMORY_MERGE value is inherited
# [RUN] test_prctl_fork_exec

^ where is the test?

# [RUN] test_prctl_unmerge
ok 8 Pages were unmerged
# Planned tests != run tests (9 != 8)
# Totals: pass:8 fail:0 xfail:0 xpass:0 skip:0 error:0

^ what?

ok 8 PR_SET_MEMORY_MERGE value is inherited
# [RUN] test_prctl_unmerge
ok 9 Pages were unmerged
# Totals: pass:9 fail:0 xfail:0 xpass:0 skip:0 error:0

^ huh, what now?

-- 
Cheers,

David / dhildenb

Re: [PATCH v2 5/7] selftests/mm: Fix child process exit codes in ksm_functional_tests

[Donet Tom]

Hi David

On 7/3/25 2:03 PM, David Hildenbrand wrote:
> On 03.07.25 08:06, Aboorva Devarajan wrote:
>> In ksm_functional_tests, test_child_ksm() returned negative values
>> to indicate errors. However, when passed to exit(), these were
>> interpreted as large unsigned values (e.g, -2 became 254), leading to
>> incorrect handling in the parent process. As a result, some tests
>> appeared to be skipped or silently failed.
>>
>> This patch changes test_child_ksm() to return positive error codes
>> (1, 2, 3) and updates test_child_ksm_err() to interpret them correctly.
>> This ensures the parent accurately detects and reports child process
>> failures.
>>
>> --------------
>> Before patch:
>> --------------
>> - [RUN] test_unmerge
>> ok 1 Pages were unmerged
>> ...
>> - [RUN] test_prctl_fork
>> - No pages got merged
>> - [RUN] test_prctl_fork_exec
>> ok 7 PR_SET_MEMORY_MERGE value is inherited
>> ...
>> Bail out! 1 out of 8 tests failed
>> - Planned tests != run tests (9 != 8)
>> - Totals: pass:7 fail:1 xfail:0 xpass:0 skip:0 error:0
>>
>> --------------
>> After patch:
>> --------------
>> - [RUN] test_unmerge
>> ok 1 Pages were unmerged
>> ...
>> - [RUN] test_prctl_fork
>> - No pages got merged
>> not ok 7 Merge in child failed
>> - [RUN] test_prctl_fork_exec
>> ok 8 PR_SET_MEMORY_MERGE value is inherited
>> ...
>> Bail out! 2 out of 9 tests failed
>> - Totals: pass:7 fail:2 xfail:0 xpass:0 skip:0 error:0
>>
>> Fixes: 6c47de3be3a0 ("selftest/mm: ksm_functional_tests: extend test 
>> case for ksm fork/exec")
>> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
>
> BTW, when I run the test, I get this weird output
>
> TAP version 13
> 1..9
> # [RUN] test_unmerge
> ok 1 Pages were unmerged
> # [RUN] test_unmerge_zero_pages
> ok 2 KSM zero pages were unmerged
> # [RUN] test_unmerge_discarded
> ok 3 Pages were unmerged
> # [RUN] test_unmerge_uffd_wp
> ok 4 Pages were unmerged
> # [RUN] test_prot_none
> ok 5 Pages were unmerged
> # [RUN] test_prctl
> ok 6 Setting/clearing PR_SET_MEMORY_MERGE works
> # [RUN] test_prctl_fork
> ok 7 PR_SET_MEMORY_MERGE value is inherited
> # [RUN] test_prctl_fork_exec
>
> ^ where is the test?
>
> # [RUN] test_prctl_unmerge
> ok 8 Pages were unmerged
> # Planned tests != run tests (9 != 8)
> # Totals: pass:8 fail:0 xfail:0 xpass:0 skip:0 error:0
>
> ^ what?
>
> ok 8 PR_SET_MEMORY_MERGE value is inherited
> # [RUN] test_prctl_unmerge
> ok 9 Pages were unmerged
> # Totals: pass:9 fail:0 xfail:0 xpass:0 skip:0 error:0
>
> ^ huh, what now?
>

The problem with the exec test is that it uses its own binary to exec.

         } else if (child_pid == 0) {
                 char *prg_name = "./ksm_functional_tests";
                 char *argv_for_program[] = { prg_name, 
FORK_EXEC_CHILD_PRG_NAME, NULL };

                 execv(prg_name, argv_for_program);
                 return;
         }

So we should run it on the same directory where the binary present.

Re: [PATCH v2 5/7] selftests/mm: Fix child process exit codes in ksm_functional_tests

[David Hildenbrand]

On 03.07.25 10:51, Donet Tom wrote:
> Hi David
> 
> On 7/3/25 2:03 PM, David Hildenbrand wrote:
>> On 03.07.25 08:06, Aboorva Devarajan wrote:
>>> In ksm_functional_tests, test_child_ksm() returned negative values
>>> to indicate errors. However, when passed to exit(), these were
>>> interpreted as large unsigned values (e.g, -2 became 254), leading to
>>> incorrect handling in the parent process. As a result, some tests
>>> appeared to be skipped or silently failed.
>>>
>>> This patch changes test_child_ksm() to return positive error codes
>>> (1, 2, 3) and updates test_child_ksm_err() to interpret them correctly.
>>> This ensures the parent accurately detects and reports child process
>>> failures.
>>>
>>> --------------
>>> Before patch:
>>> --------------
>>> - [RUN] test_unmerge
>>> ok 1 Pages were unmerged
>>> ...
>>> - [RUN] test_prctl_fork
>>> - No pages got merged
>>> - [RUN] test_prctl_fork_exec
>>> ok 7 PR_SET_MEMORY_MERGE value is inherited
>>> ...
>>> Bail out! 1 out of 8 tests failed
>>> - Planned tests != run tests (9 != 8)
>>> - Totals: pass:7 fail:1 xfail:0 xpass:0 skip:0 error:0
>>>
>>> --------------
>>> After patch:
>>> --------------
>>> - [RUN] test_unmerge
>>> ok 1 Pages were unmerged
>>> ...
>>> - [RUN] test_prctl_fork
>>> - No pages got merged
>>> not ok 7 Merge in child failed
>>> - [RUN] test_prctl_fork_exec
>>> ok 8 PR_SET_MEMORY_MERGE value is inherited
>>> ...
>>> Bail out! 2 out of 9 tests failed
>>> - Totals: pass:7 fail:2 xfail:0 xpass:0 skip:0 error:0
>>>
>>> Fixes: 6c47de3be3a0 ("selftest/mm: ksm_functional_tests: extend test
>>> case for ksm fork/exec")
>>> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
>>
>> BTW, when I run the test, I get this weird output
>>
>> TAP version 13
>> 1..9
>> # [RUN] test_unmerge
>> ok 1 Pages were unmerged
>> # [RUN] test_unmerge_zero_pages
>> ok 2 KSM zero pages were unmerged
>> # [RUN] test_unmerge_discarded
>> ok 3 Pages were unmerged
>> # [RUN] test_unmerge_uffd_wp
>> ok 4 Pages were unmerged
>> # [RUN] test_prot_none
>> ok 5 Pages were unmerged
>> # [RUN] test_prctl
>> ok 6 Setting/clearing PR_SET_MEMORY_MERGE works
>> # [RUN] test_prctl_fork
>> ok 7 PR_SET_MEMORY_MERGE value is inherited
>> # [RUN] test_prctl_fork_exec
>>
>> ^ where is the test?
>>
>> # [RUN] test_prctl_unmerge
>> ok 8 Pages were unmerged
>> # Planned tests != run tests (9 != 8)
>> # Totals: pass:8 fail:0 xfail:0 xpass:0 skip:0 error:0
>>
>> ^ what?
>>
>> ok 8 PR_SET_MEMORY_MERGE value is inherited
>> # [RUN] test_prctl_unmerge
>> ok 9 Pages were unmerged
>> # Totals: pass:9 fail:0 xfail:0 xpass:0 skip:0 error:0
>>
>> ^ huh, what now?
>>
> 
> The problem with the exec test is that it uses its own binary to exec.
> 
>           } else if (child_pid == 0) {
>                   char *prg_name = "./ksm_functional_tests";
>                   char *argv_for_program[] = { prg_name,
> FORK_EXEC_CHILD_PRG_NAME, NULL };
> 
>                   execv(prg_name, argv_for_program);
>                   return;
>           }
 > > So we should run it on the same directory where the binary present.

So, I assume the execv fails. We should handle that, and figure out why 
it fails.

diff --git a/tools/testing/selftests/mm/ksm_functional_tests.c 
b/tools/testing/selftests/mm/ksm_functional_tests.c
index d8bd1911dfc0a..0ddbb390df33b 100644
--- a/tools/testing/selftests/mm/ksm_functional_tests.c
+++ b/tools/testing/selftests/mm/ksm_functional_tests.c
@@ -527,6 +527,8 @@ static void test_child_ksm_err(int status)
                 ksft_test_result_fail("Merge in child failed\n");
         else if (status == -3)
                 ksft_test_result_skip("Merge in child skipped\n");
+       else if (status == 4)
+               ksft_test_result_fail("Binary not found\n");
  }

  /* Verify that prctl ksm flag is inherited. */
@@ -598,7 +600,7 @@ static void test_prctl_fork_exec(void)
                 char *argv_for_program[] = { prg_name, 
FORK_EXEC_CHILD_PRG_NAME };

                 execv(prg_name, argv_for_program);
-               return;
+               exit(4);
         }

         if (waitpid(child_pid, &status, 0) > 0) {

results in

TAP version 13
1..9
# [RUN] test_unmerge
ok 1 Pages were unmerged
# [RUN] test_unmerge_zero_pages
ok 2 KSM zero pages were unmerged
# [RUN] test_unmerge_discarded
ok 3 Pages were unmerged
# [RUN] test_unmerge_uffd_wp
ok 4 Pages were unmerged
# [RUN] test_prot_none
ok 5 Pages were unmerged
# [RUN] test_prctl
ok 6 Setting/clearing PR_SET_MEMORY_MERGE works
# [RUN] test_prctl_fork
ok 7 PR_SET_MEMORY_MERGE value is inherited
# [RUN] test_prctl_fork_exec
not ok 8 Binary not found
# [RUN] test_prctl_unmerge
ok 9 Pages were unmerged
Bail out! 1 out of 9 tests failed
# Totals: pass:8 fail:1 xfail:0 xpass:0 skip:0 error:0


-- 
Cheers,

David / dhildenb

Re: [PATCH v2 5/7] selftests/mm: Fix child process exit codes in ksm_functional_tests

[Donet Tom]

On 7/3/25 2:44 PM, David Hildenbrand wrote:
> On 03.07.25 10:51, Donet Tom wrote:
>> Hi David
>>
>> On 7/3/25 2:03 PM, David Hildenbrand wrote:
>>> On 03.07.25 08:06, Aboorva Devarajan wrote:
>>>> In ksm_functional_tests, test_child_ksm() returned negative values
>>>> to indicate errors. However, when passed to exit(), these were
>>>> interpreted as large unsigned values (e.g, -2 became 254), leading to
>>>> incorrect handling in the parent process. As a result, some tests
>>>> appeared to be skipped or silently failed.
>>>>
>>>> This patch changes test_child_ksm() to return positive error codes
>>>> (1, 2, 3) and updates test_child_ksm_err() to interpret them 
>>>> correctly.
>>>> This ensures the parent accurately detects and reports child process
>>>> failures.
>>>>
>>>> --------------
>>>> Before patch:
>>>> --------------
>>>> - [RUN] test_unmerge
>>>> ok 1 Pages were unmerged
>>>> ...
>>>> - [RUN] test_prctl_fork
>>>> - No pages got merged
>>>> - [RUN] test_prctl_fork_exec
>>>> ok 7 PR_SET_MEMORY_MERGE value is inherited
>>>> ...
>>>> Bail out! 1 out of 8 tests failed
>>>> - Planned tests != run tests (9 != 8)
>>>> - Totals: pass:7 fail:1 xfail:0 xpass:0 skip:0 error:0
>>>>
>>>> --------------
>>>> After patch:
>>>> --------------
>>>> - [RUN] test_unmerge
>>>> ok 1 Pages were unmerged
>>>> ...
>>>> - [RUN] test_prctl_fork
>>>> - No pages got merged
>>>> not ok 7 Merge in child failed
>>>> - [RUN] test_prctl_fork_exec
>>>> ok 8 PR_SET_MEMORY_MERGE value is inherited
>>>> ...
>>>> Bail out! 2 out of 9 tests failed
>>>> - Totals: pass:7 fail:2 xfail:0 xpass:0 skip:0 error:0
>>>>
>>>> Fixes: 6c47de3be3a0 ("selftest/mm: ksm_functional_tests: extend test
>>>> case for ksm fork/exec")
>>>> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
>>>
>>> BTW, when I run the test, I get this weird output
>>>
>>> TAP version 13
>>> 1..9
>>> # [RUN] test_unmerge
>>> ok 1 Pages were unmerged
>>> # [RUN] test_unmerge_zero_pages
>>> ok 2 KSM zero pages were unmerged
>>> # [RUN] test_unmerge_discarded
>>> ok 3 Pages were unmerged
>>> # [RUN] test_unmerge_uffd_wp
>>> ok 4 Pages were unmerged
>>> # [RUN] test_prot_none
>>> ok 5 Pages were unmerged
>>> # [RUN] test_prctl
>>> ok 6 Setting/clearing PR_SET_MEMORY_MERGE works
>>> # [RUN] test_prctl_fork
>>> ok 7 PR_SET_MEMORY_MERGE value is inherited
>>> # [RUN] test_prctl_fork_exec
>>>
>>> ^ where is the test?
>>>
>>> # [RUN] test_prctl_unmerge
>>> ok 8 Pages were unmerged
>>> # Planned tests != run tests (9 != 8)
>>> # Totals: pass:8 fail:0 xfail:0 xpass:0 skip:0 error:0
>>>
>>> ^ what?
>>>
>>> ok 8 PR_SET_MEMORY_MERGE value is inherited
>>> # [RUN] test_prctl_unmerge
>>> ok 9 Pages were unmerged
>>> # Totals: pass:9 fail:0 xfail:0 xpass:0 skip:0 error:0
>>>
>>> ^ huh, what now?
>>>
>>
>> The problem with the exec test is that it uses its own binary to exec.
>>
>>           } else if (child_pid == 0) {
>>                   char *prg_name = "./ksm_functional_tests";
>>                   char *argv_for_program[] = { prg_name,
>> FORK_EXEC_CHILD_PRG_NAME, NULL };
>>
>>                   execv(prg_name, argv_for_program);
>>                   return;
>>           }
> > > So we should run it on the same directory where the binary present.
>
> So, I assume the execv fails. We should handle that, and figure out 
> why it fails.
>
> diff --git a/tools/testing/selftests/mm/ksm_functional_tests.c 
> b/tools/testing/selftests/mm/ksm_functional_tests.c
> index d8bd1911dfc0a..0ddbb390df33b 100644
> --- a/tools/testing/selftests/mm/ksm_functional_tests.c
> +++ b/tools/testing/selftests/mm/ksm_functional_tests.c
> @@ -527,6 +527,8 @@ static void test_child_ksm_err(int status)
>                 ksft_test_result_fail("Merge in child failed\n");
>         else if (status == -3)
>                 ksft_test_result_skip("Merge in child skipped\n");
> +       else if (status == 4)
> +               ksft_test_result_fail("Binary not found\n");
>  }
>
>  /* Verify that prctl ksm flag is inherited. */
> @@ -598,7 +600,7 @@ static void test_prctl_fork_exec(void)
>                 char *argv_for_program[] = { prg_name, 
> FORK_EXEC_CHILD_PRG_NAME };
>
>                 execv(prg_name, argv_for_program);
> -               return;
> +               exit(4);
>         }
>
>         if (waitpid(child_pid, &status, 0) > 0) {
>
> results in
>
> TAP version 13
> 1..9
> # [RUN] test_unmerge
> ok 1 Pages were unmerged
> # [RUN] test_unmerge_zero_pages
> ok 2 KSM zero pages were unmerged
> # [RUN] test_unmerge_discarded
> ok 3 Pages were unmerged
> # [RUN] test_unmerge_uffd_wp
> ok 4 Pages were unmerged
> # [RUN] test_prot_none
> ok 5 Pages were unmerged
> # [RUN] test_prctl
> ok 6 Setting/clearing PR_SET_MEMORY_MERGE works
> # [RUN] test_prctl_fork
> ok 7 PR_SET_MEMORY_MERGE value is inherited
> # [RUN] test_prctl_fork_exec
> not ok 8 Binary not found
> # [RUN] test_prctl_unmerge
> ok 9 Pages were unmerged
> Bail out! 1 out of 9 tests failed
> # Totals: pass:8 fail:1 xfail:0 xpass:0 skip:0 error:0


Thanks David.

We will add this in next version.


>
>

[PATCH v2 6/7] selftests/mm: Skip thuge-gen if shmmax is too small or no 1G huge pages

[Aboorva Devarajan]

Make thuge-gen skip instead of fail when it can't run due to system
settings. If shmmax is too small or no 1G huge pages are available,
the test now prints a warning and is marked as skipped.

-------------------
Before Patch:
-------------------
~ running ./thuge-gen
~ Bail out! Please do echo 262144 > /proc/sys/kernel/shmmax
~ Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0
~ [FAIL]
not ok 28 thuge-gen ~ exit=1

-------------------
After Patch:
-------------------
~ running ./thuge-gen
~ ~ WARNING: shmmax is too small to run this test.
~ ~ Please run the following command to increase shmmax:
~ ~ echo 262144 > /proc/sys/kernel/shmmax
~ 1..0 ~ SKIP Test skipped due to insufficient shmmax value.
~ [SKIP]
ok 29 thuge-gen ~ SKIP

Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
---
 tools/testing/selftests/mm/thuge-gen.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/mm/thuge-gen.c b/tools/testing/selftests/mm/thuge-gen.c
index 8e2b08dc5762..4f5e290ff1a6 100644
--- a/tools/testing/selftests/mm/thuge-gen.c
+++ b/tools/testing/selftests/mm/thuge-gen.c
@@ -177,13 +177,16 @@ void find_pagesizes(void)
 	globfree(&g);
 
 	read_sysfs("/proc/sys/kernel/shmmax", &shmmax_val);
-	if (shmmax_val < NUM_PAGES * largest)
-		ksft_exit_fail_msg("Please do echo %lu > /proc/sys/kernel/shmmax",
-				   largest * NUM_PAGES);
+	if (shmmax_val < NUM_PAGES * largest) {
+		ksft_print_msg("WARNING: shmmax is too small to run this test.\n");
+		ksft_print_msg("Please run the following command to increase shmmax:\n");
+		ksft_print_msg("echo %lu > /proc/sys/kernel/shmmax\n", largest * NUM_PAGES);
+		ksft_exit_skip("Test skipped due to insufficient shmmax value.\n");
+	}
 
 #if defined(__x86_64__)
 	if (largest != 1U<<30) {
-		ksft_exit_fail_msg("No GB pages available on x86-64\n"
+		ksft_exit_skip("No GB pages available on x86-64\n"
 				   "Please boot with hugepagesz=1G hugepages=%d\n", NUM_PAGES);
 	}
 #endif
-- 
2.43.5

Re: [PATCH v2 6/7] selftests/mm: Skip thuge-gen if shmmax is too small or no 1G huge pages

[Dev Jain]

On 03/07/25 11:36 am, Aboorva Devarajan wrote:
> Make thuge-gen skip instead of fail when it can't run due to system
> settings. If shmmax is too small or no 1G huge pages are available,
> the test now prints a warning and is marked as skipped.
>
> -------------------
> Before Patch:
> -------------------
> ~ running ./thuge-gen
> ~ Bail out! Please do echo 262144 > /proc/sys/kernel/shmmax
> ~ Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0
> ~ [FAIL]
> not ok 28 thuge-gen ~ exit=1
>
> -------------------
> After Patch:
> -------------------
> ~ running ./thuge-gen
> ~ ~ WARNING: shmmax is too small to run this test.
> ~ ~ Please run the following command to increase shmmax:
> ~ ~ echo 262144 > /proc/sys/kernel/shmmax
> ~ 1..0 ~ SKIP Test skipped due to insufficient shmmax value.
> ~ [SKIP]
> ok 29 thuge-gen ~ SKIP
>
> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
> ---

LGTM

Reviewed-by: Dev Jain <dev.jain@arm.com>

Re: [PATCH v2 6/7] selftests/mm: Skip thuge-gen if shmmax is too small or no 1G huge pages

[David Hildenbrand]

On 03.07.25 08:06, Aboorva Devarajan wrote:
> Make thuge-gen skip instead of fail when it can't run due to system
> settings. If shmmax is too small or no 1G huge pages are available,
> the test now prints a warning and is marked as skipped.

Maybe change the subject to

"selftests/mm: Skip thuge-gen test if system is not setup properly"

> 
> -------------------
> Before Patch:
> -------------------
> ~ running ./thuge-gen
> ~ Bail out! Please do echo 262144 > /proc/sys/kernel/shmmax
> ~ Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0
> ~ [FAIL]
> not ok 28 thuge-gen ~ exit=1
> 
> -------------------
> After Patch:
> -------------------
> ~ running ./thuge-gen
> ~ ~ WARNING: shmmax is too small to run this test.
> ~ ~ Please run the following command to increase shmmax:
> ~ ~ echo 262144 > /proc/sys/kernel/shmmax
> ~ 1..0 ~ SKIP Test skipped due to insufficient shmmax value.
> ~ [SKIP]
> ok 29 thuge-gen ~ SKIP
> 

Acked-by: David Hildenbrand <david@redhat.com>

-- 
Cheers,

David / dhildenb

Re: [PATCH v2 6/7] selftests/mm: Skip thuge-gen if shmmax is too small or no 1G huge pages

[Zi Yan]

On 3 Jul 2025, at 2:06, Aboorva Devarajan wrote:

> Make thuge-gen skip instead of fail when it can't run due to system
> settings. If shmmax is too small or no 1G huge pages are available,
> the test now prints a warning and is marked as skipped.
>
> -------------------
> Before Patch:
> -------------------
> ~ running ./thuge-gen
> ~ Bail out! Please do echo 262144 > /proc/sys/kernel/shmmax
> ~ Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0
> ~ [FAIL]
> not ok 28 thuge-gen ~ exit=1
>
> -------------------
> After Patch:
> -------------------
> ~ running ./thuge-gen
> ~ ~ WARNING: shmmax is too small to run this test.
> ~ ~ Please run the following command to increase shmmax:
> ~ ~ echo 262144 > /proc/sys/kernel/shmmax
> ~ 1..0 ~ SKIP Test skipped due to insufficient shmmax value.
> ~ [SKIP]
> ok 29 thuge-gen ~ SKIP
>
> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
> ---
>  tools/testing/selftests/mm/thuge-gen.c | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
>
Reviewed-by: Zi Yan <ziy@nvidia.com>

Best Regards,
Yan, Zi

[PATCH v2 7/7] selftests/mm: Skip hugepage-mremap test if userfaultfd unavailable

[Aboorva Devarajan]

Gracefully skip test if userfaultfd is not supported (ENOSYS) or not
permitted (EPERM), instead of failing. This avoids misleading failures
with clear skip messages.
--------------
Before Patch
--------------
~ running ./hugepage-mremap
...
~ Bail out! userfaultfd: Function not implemented
~ Planned tests != run tests (1 != 0)
~ Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0
~ [FAIL]
not ok 4 hugepage-mremap # exit=1

--------------
After Patch
--------------
~ running ./hugepage-mremap
...
~ ok 2 # SKIP userfaultfd is not supported/not enabled.
~ 1 skipped test(s) detected.
~ Totals: pass:0 fail:0 xfail:0 xpass:0 skip:1 error:0
~ [SKIP]
ok 4 hugepage-mremap # SKIP

Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
---
 tools/testing/selftests/mm/hugepage-mremap.c | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/mm/hugepage-mremap.c b/tools/testing/selftests/mm/hugepage-mremap.c
index c463d1c09c9b..1a0e6dd87578 100644
--- a/tools/testing/selftests/mm/hugepage-mremap.c
+++ b/tools/testing/selftests/mm/hugepage-mremap.c
@@ -65,10 +65,20 @@ static void register_region_with_uffd(char *addr, size_t len)
 	struct uffdio_api uffdio_api;
 
 	/* Create and enable userfaultfd object. */
-
 	uffd = syscall(__NR_userfaultfd, O_CLOEXEC | O_NONBLOCK);
-	if (uffd == -1)
-		ksft_exit_fail_msg("userfaultfd: %s\n", strerror(errno));
+	if (uffd == -1) {
+		switch (errno) {
+		case EPERM:
+			ksft_exit_skip("No userfaultfd permissions, try running as root.\n");
+			break;
+		case ENOSYS:
+			ksft_exit_skip("userfaultfd is not supported/not enabled.\n");
+			break;
+		default:
+			ksft_exit_fail_msg("userfaultfd failed with %s\n", strerror(errno));
+			break;
+		}
+	}
 
 	uffdio_api.api = UFFD_API;
 	uffdio_api.features = 0;
-- 
2.43.5

Re: [PATCH v2 7/7] selftests/mm: Skip hugepage-mremap test if userfaultfd unavailable

[David Hildenbrand]

On 03.07.25 08:06, Aboorva Devarajan wrote:
> Gracefully skip test if userfaultfd is not supported (ENOSYS) or not
> permitted (EPERM), instead of failing. This avoids misleading failures
> with clear skip messages.
> --------------
> Before Patch
> --------------
> ~ running ./hugepage-mremap
> ...
> ~ Bail out! userfaultfd: Function not implemented
> ~ Planned tests != run tests (1 != 0)
> ~ Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0
> ~ [FAIL]
> not ok 4 hugepage-mremap # exit=1
> 
> --------------
> After Patch
> --------------
> ~ running ./hugepage-mremap
> ...
> ~ ok 2 # SKIP userfaultfd is not supported/not enabled.
> ~ 1 skipped test(s) detected.
> ~ Totals: pass:0 fail:0 xfail:0 xpass:0 skip:1 error:0
> ~ [SKIP]
> ok 4 hugepage-mremap # SKIP
> 
> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
> ---
>   tools/testing/selftests/mm/hugepage-mremap.c | 16 +++++++++++++---
>   1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/testing/selftests/mm/hugepage-mremap.c b/tools/testing/selftests/mm/hugepage-mremap.c
> index c463d1c09c9b..1a0e6dd87578 100644
> --- a/tools/testing/selftests/mm/hugepage-mremap.c
> +++ b/tools/testing/selftests/mm/hugepage-mremap.c
> @@ -65,10 +65,20 @@ static void register_region_with_uffd(char *addr, size_t len)
>   	struct uffdio_api uffdio_api;
>   
>   	/* Create and enable userfaultfd object. */
> -
>   	uffd = syscall(__NR_userfaultfd, O_CLOEXEC | O_NONBLOCK);
> -	if (uffd == -1)
> -		ksft_exit_fail_msg("userfaultfd: %s\n", strerror(errno));
> +	if (uffd == -1) {
> +		switch (errno) {
> +		case EPERM:
> +			ksft_exit_skip("No userfaultfd permissions, try running as root.\n");

"Insufficient permissions, try ..." ?

> +			break;
> +		case ENOSYS:
> +			ksft_exit_skip("userfaultfd is not supported/not enabled.\n");
> +			break;

Note that we have in tools/testing/selftests/mm/config

	CONFIG_USERFAULTFD=y

But I don't have anything about making the test more versatile.

Acked-by: David Hildenbrand <david@redhat.com>

-- 
Cheers,

David / dhildenb

Re: [PATCH v2 7/7] selftests/mm: Skip hugepage-mremap test if userfaultfd unavailable

[Zi Yan]

On 3 Jul 2025, at 4:38, David Hildenbrand wrote:

> On 03.07.25 08:06, Aboorva Devarajan wrote:
>> Gracefully skip test if userfaultfd is not supported (ENOSYS) or not
>> permitted (EPERM), instead of failing. This avoids misleading failures
>> with clear skip messages.
>> --------------
>> Before Patch
>> --------------
>> ~ running ./hugepage-mremap
>> ...
>> ~ Bail out! userfaultfd: Function not implemented
>> ~ Planned tests != run tests (1 != 0)
>> ~ Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0
>> ~ [FAIL]
>> not ok 4 hugepage-mremap # exit=1
>>
>> --------------
>> After Patch
>> --------------
>> ~ running ./hugepage-mremap
>> ...
>> ~ ok 2 # SKIP userfaultfd is not supported/not enabled.
>> ~ 1 skipped test(s) detected.
>> ~ Totals: pass:0 fail:0 xfail:0 xpass:0 skip:1 error:0
>> ~ [SKIP]
>> ok 4 hugepage-mremap # SKIP
>>
>> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
>> ---
>>   tools/testing/selftests/mm/hugepage-mremap.c | 16 +++++++++++++---
>>   1 file changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/testing/selftests/mm/hugepage-mremap.c b/tools/testing/selftests/mm/hugepage-mremap.c
>> index c463d1c09c9b..1a0e6dd87578 100644
>> --- a/tools/testing/selftests/mm/hugepage-mremap.c
>> +++ b/tools/testing/selftests/mm/hugepage-mremap.c
>> @@ -65,10 +65,20 @@ static void register_region_with_uffd(char *addr, size_t len)
>>   	struct uffdio_api uffdio_api;
>>    	/* Create and enable userfaultfd object. */
>> -
>>   	uffd = syscall(__NR_userfaultfd, O_CLOEXEC | O_NONBLOCK);
>> -	if (uffd == -1)
>> -		ksft_exit_fail_msg("userfaultfd: %s\n", strerror(errno));
>> +	if (uffd == -1) {
>> +		switch (errno) {
>> +		case EPERM:
>> +			ksft_exit_skip("No userfaultfd permissions, try running as root.\n");
>
> "Insufficient permissions, try ..." ?
>
>> +			break;
>> +		case ENOSYS:
>> +			ksft_exit_skip("userfaultfd is not supported/not enabled.\n");
>> +			break;
>
> Note that we have in tools/testing/selftests/mm/config
>
> 	CONFIG_USERFAULTFD=y

I added the same fix to guard-regions.c since I did not know the config
file existed.

And from git history, I learnt that I could use the command below to merge
these config to my local config:
“./scripts/kconfig/merge_config.sh .config tools/testing/selftests/xxx/config”

Reviewed-by: Zi Yan <ziy@nvidia.com>

Best Regards,
Yan, Zi