Re: [PATCH] selftests/mm: add THP sysfs interface test

["David Hildenbrand (Arm)" <david@kernel.org>]

On 3/16/26 14:47, Breno Leitao wrote:
> On Mon, Mar 16, 2026 at 12:55:13PM +0000, Lorenzo Stoakes (Oracle) wrote:
>> On Mon, Mar 09, 2026 at 05:00:34AM -0700, Breno Leitao wrote:
>>> Add a shell-based selftest that exercises the full set of THP sysfs
>>> knobs: enabled (global and per-size anon), defrag, use_zero_page,
>>> hpage_pmd_size, shmem_enabled (global and per-size), shrink_underused,
>>> khugepaged/ tunables, and per-size stats files.
>>>
>>> Each writable knob is tested for valid writes, invalid-input rejection,
>>> idempotent writes, and mode transitions where applicable. All original
>>> values are saved before testing and restored afterwards.
>>>
>>> The test uses the kselftest KTAP framework (ktap_helpers.sh) for
>>> structured TAP 13 output, making results parseable by the kselftest
>>> harness. The test plan is printed at the end since the number of test
>>> points is dynamic (depends on available hugepage sizes and sysfs files).
>>>
>>> This is particularly useful for validating the refactoring of
>>> enabled_store() and anon_enabled_store() to use sysfs_match_string()
>>> and the new change_enabled()/change_anon_orders() helpers.
>>>
>>> Signed-off-by: Breno Leitao <leitao@debian.org>
>>
>> The test is broken locally for me, returning error code 127.
>>
>> I do appreciate the effort here, so I'm sorry to push back negatively, but I
>> feel a bash script here is pretty janky, and frankly if any of these interfaces
>> were as broken as this it'd be a major failure that would surely get picked up
>> far sooner elsewhere.
>>
>> So while I think this might be useful as a local test for your sysfs interface
>> changes, I don't think this is really suited to the mm selftests.
> 
> That is totally fine. This test is what I have been using to test the
> changes, and I decide to share it in case someone find it useful.
> 
> Let's drop it.

Out of interest, to we know why the test is failing for Lorenzo?

I agree that the test is a bit excessive, in particular when it comes to
invalid/idempotent values etc. I could see some value for testing
whether setting the modes keeps working, but also then I wonder if that
is really something we'll be changing frequently (and that breaks easily).

-- 
Cheers,

David