Re: [PATCH RFC 0/4] selftests: harness: Provide global metadata pointer to allow clean teardown from selftest libraries

[Ackerley Tng]

Sean Christopherson <seanjc@xxxxxxxxxx> writes:

> On Tue, Apr 14, 2026, Ackerley Tng wrote:
>> Sean suggested using setjmp and longjmp [1] to back to the top level
>> TEST_F(). I looked at [1] and found myself wishing to use TEST_F() the from
>> kselftest harness directly.
>
> Can you elaborate?  If you have a need for direct TEST_F() in KVM selftests, odds
> are good someone/something else will have a similar need, sooner or later.
>

I guess I like the consistency of working with TEST_F(), there's also
TEST_F_TIMEOUT() and friends and all the usefulness of the rest of the
kselftest_harness as you described, all of which will probably need
re-wrapping if we proceed with the approach of wrapping.

>> Also, setjmp/longjmp felt like it was introducing state that could be messed
>> up easily.
>
> Meh, same goes for the kselftests_harness.h.  I can point you at a half dozen
> bugs where enhancements to the core framework wreaked havoc for unsuspecting
> subsystems.  I'm not trying to throw shade at the harness; there's a _lot_ of
> goodness in there.  My point is that doing complex things that impact a huge
> variety of downstream users is going to have many sharp edges, regardless of
> where the complexity resides.
>
> I'm not wedded to setjmp/longjmp by any means, but for me this isn't a compelling
> argument against the approach.
>
>> I also found recent work that removed setjmp/longjmp from kselftest harness
>> [2].
>
> KVM selftests don't support building with nolibc.
>

Not particularly against setting it up with setjmp/longjmp either, I
think the discussion here is mostly between

1. Wrap kselftest_harness for KVM
2. Improving kselftest_harness so KVM can benefit from it

setjmp/longjmp has already been removed from kselftest_harness so that
option doesn't make sense if we go with (2).

If we go with (1), I could (a) store the _metadata pointer in a global
variable within KVM or (b) go with setjmp/longjmp (c) some other
suggestion.

>> The kselftests harness is running tests sequentially anyway, and the
>> function pointers in _metadata wouldn't be changing all that often in most
>> selftests.
>>
>> Would maintainers be open to having the kselftest harness expose a pointer
>> to the metadata globally?
>>
>> Another option would be to expose the current teardown function pointer
>> globally instead of the pointer to the entire metadata struct.
>
> I'm strongly opposed to any idea effectively requires special casing KVM selftests
> in the common harness.  In my experience, the common harness is already quite
> brittle, in large part because there is no singular maintainer(s) that is responsible
> for ensuring changes work for all downstream users.  Adding odd bits of code that
> is only ever used by a handful of KVM selftests is only going to increase the
> probability that that code is broken.

If Kees likes the idea of exposing a pointer to the metadata globally,
does that make KVM selftests less "special"?

If the community likes the global metadata pointer, I could update the
harness to adopt the global metadata pointer and then KVM wouldn't be
special at all.