[PATCH] tests: allow tests to append tunables

[Adhemerval Zanella Netto]

On 15/04/26 05:28, Yury Khrustalev wrote:
> Hi Adhemerval,
> 
> You are responding to v1 while there is already v2 as per Carlos'
> request and as discussed during the weekly call on Monday:
> 
> https://inbox.sourceware.org/libc-alpha/20260413142618.405790-1-yury.khrustalev@arm.com/
> 
> On Tue, Apr 14, 2026 at 04:25:01PM -0300, Adhemerval Zanella Netto wrote:
>>
>>
>> On 24/03/26 11:14, Yury Khrustalev wrote:
>>> Many tests use Glibc tunables. The tunable values are provided via
>>> the GLIBC_TUNABLES env variable. Tests set it in makefiles using
>>>
>>>   tst-foo-ENV = GLIBC_TUNABLES=tunable=value
>>>
>>> This overwrites environment for this test, so if another env var is
>>> set elsewhere, one of these changes would be lost. The correct way
>>> should be to append to test's environment:
>>>
>>>   tst-foo-ENV += GLIBC_TUNABLES=tunable=value
>>>
>>> However, if two or more tunables need to be set for the same test,
>>> the 'tunable=value' part should be appended to previously defined
>>> GLIBC_TUNABLES env variable.
>>>
>>> This commit adds 'tunable-add' that can be used to correctly append
>>> another tunable to a test's environment. We also change tests in the
>>> malloc and misc folder.
>>>
>>> ---
>>> base-commit: 9f5f18aab4
>>> passes regression on aarch64 and x86-64
>>
>> It is not clear to me why we need tunables to be composable.
> 
> The answer to this is right above in the commit message. If you need
> more examples, here they are:
> 
> 1) Testing memory tagging requires using the memtag tunable along with
>    any other tunables that are already used by malloc and other tests.

The current approach for malloc-check, malloc-hugetlb1, etc. to imply an 
specific environment/tunable is straightforward to understand the test
constraints, and it avoids false-positive if someone messes with the
environment (like if GLIBC_TUNABLES is defined in the environment).

The question is if really need to make *all* malloc (or any other test)
composable to have good test coverage for a specific features.  Even for 
hugetlb, there are some tests we need exclude, so maybe adding all malloc
tests was not a good idea and should make it test by test.

> 
> 2) Another example (that is not yet addressed in this patch but it's an
>    easy extension), is that, when we run tests on a GCS (or BTI etc)
>    system, we want to enable GCS for all tests by using something like
> 
>      GLIBC_TUNABLES=glibc.cpu.aarch64_gcs=1 make check

But does it make sense for all tests with all the tunable support? It might
work with GCS (with some extra care to filter-out for tests where GCS should
be disabled, an this adds an extra layer of complexity).

Maybe add a support/test-container.c support to enable GCS/BTI/etc, and gate
through a different environment (only meant to be used during glibc testsing)
instead of adding this support to enable any tunable through make check.

> 
>    However currently this would only apply to the tests that don't
>    override environment (even if they do so for something other than
>    tunables).
> 
>> I would 
>> expect that cflags, ldflags, and any other build definition to might 
>> require arch specific overrides.
> 
> This seems not related to the patch at all.

My point here is some test definitions do makes sense to be composable, where
you need arch-specific environment specifications. For some tests we do
this through source code (for instance elf/tst-gnu2-tls*).

> 
>>
>> Also using a make rule to is not much ergonomic, it requires to trace all
>> the previous ENV and other definitions to have the final tunable value.
>> I think it is more clear to have clear place where the testing setup is
>> set.
>>
>> Maybe something move simpler would to have:
>>
>>   tst-foo-TUNABLE1 = ...:
>>   tst-foo-TUNABLE2 += ...
>>
>> and then a rule to join all of them.
> 
> I might consider this, although I'm not sure what you mean by TUNABLE1
> and TUNABLE2. This seems like a feature creep.
> 
> Please comment on the recent version of the patch, thanks.


>> If it is better to use something like as suggested in [1]
>> 
>>   tst-foo-TUNABLES
>> 
>> instead of modifying the whole environment of the test via
>> 
>>   tst-foo-ENV += GLIBC_TUNABLES=tunable=value
>> 
>> or
>> 
>>   $(eval $(call tunable-add, ...))
>> 
>> I can certainly look into this and send another patch. This might be a
>> better way of doing it.

The main question if we really need to run *all* malloc tests with memtag,
of if we can just use a malloc-memtag-ENVS instead.