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

[Sean Christopherson <seanjc@google.com>]

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.

> 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.

> 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.