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

[Sayali Patil <sayalip@linux.ibm.com>]

On 26/06/26 20:18, Usama Arif wrote:
> On Thu, 25 Jun 2026 18:10:16 +0530 Sayali Patil <sayalip@linux.ibm.com> wrote:
> 
>> Some MM selftests attempt to configure the amount of
>> HugeTLB pages of different sizes by writing to nr_hugepages.
>>
>> PowerPC hash MMU pSeries systems advertise gigantic hugepage sizes
>> but do not support runtime allocation of such pages, writes
>> to the corresponding nr_hugepages file fail with -EINVAL.
>> This causes the test to bail out even though the failure is due
>> to a platform limitation rather than the
>> functionality being tested.
>>
>> Treat -EINVAL from the sysfs write as a skipped configuration request
>> and continue running the test instead of failing.
>>
>> Before patch:
>>     -------------------------
>>     running ./hugetlb-madvise
>>     -------------------------
>>     TAP version 13
>>     1..1
>>       [INFO] detected hugetlb page size: 16777216 KiB
>>       [INFO] detected hugetlb page size: 16384 KiB
>>      ok 1 MADV_DONTNEED and MADV_REMOVE on hugetlb
>>      Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
>>      Bail out! /sys/kernel/mm/hugepages/hugepages-16777216kB/nr_hugepages
>>      write(0) failed: Invalid argument
>>      Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0
>>      [FAIL]
>>
>> After patch:
>>     -------------------------
>>     running ./hugetlb-madvise
>>     -------------------------
>>     TAP version 13
>>     1..1
>>      [INFO] detected hugetlb page size: 16777216 KiB
>>      [INFO] detected hugetlb page size: 16384 KiB
>>     ok 1 MADV_DONTNEED and MADV_REMOVE on hugetlb
>>     Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
>>     /sys/kernel/mm/hugepages/hugepages-16777216kB/nr_hugepages
>>     write(0) failed: Invalid argument
>>     [PASS]
>>
>> Fixes: 9d07250ea1eb ("selftests/mm: hugepage_settings: add APIs to get and set nr_hugepages")
>> Signed-off-by: Sayali Patil <sayalip@linux.ibm.com>
>> ---
>>   tools/testing/selftests/mm/vm_util.c | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/tools/testing/selftests/mm/vm_util.c b/tools/testing/selftests/mm/vm_util.c
>> index 311fc5b4513e..a8f16eef5c7c 100644
>> --- a/tools/testing/selftests/mm/vm_util.c
>> +++ b/tools/testing/selftests/mm/vm_util.c
>> @@ -735,6 +735,13 @@ void write_file(const char *path, const char *buf, size_t buflen)
>>   	saved_errno = errno;
>>   	close(fd);
>>   	errno = saved_errno;
>> +
>> +	if (numwritten < 0 && errno == EINVAL) {
>> +		ksft_print_msg("%s write(%.*s) failed: %s\n", path,
>> +			       (int)(buflen - 1), buf, strerror(errno));
>> +		return;
>> +	}
>> +
> This makes write_file() silently succeed for every EINVAL, not just the
> gigantic-hugetlb setup case. Several callers use this helper for writes where
> EINVAL is a real test failure, for example drop_caches or split huge page
> setup. Those tests can now continue after a failed setup and report misleading
> results.
> 
> Please keep the common helper strict and ignore EINVAL only in the hugetlb
> path that is probing unsupported gigantic page runtime allocation.

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

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

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