* Re: [PATCH RFC 0/4] selftests: harness: Provide global metadata pointer to allow clean teardown from selftest libraries
[not found] <20260414-selftest-global-metadata-v1-0-fd223922bc57@google.com>
@ 2026-05-12 20:24 ` Sean Christopherson
2026-05-13 1:01 ` Kees Cook
1 sibling, 0 replies; 2+ messages in thread
From: Sean Christopherson @ 2026-05-12 20:24 UTC (permalink / raw)
To: Ackerley Tng
Cc: Kees Cook, Andy Lutomirski, Will Drewry, Shuah Khan,
Paolo Bonzini, thomas.weissschuh, linux, linux-kernel,
linux-kselftest, kvm
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.
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: [PATCH RFC 0/4] selftests: harness: Provide global metadata pointer to allow clean teardown from selftest libraries
[not found] <20260414-selftest-global-metadata-v1-0-fd223922bc57@google.com>
2026-05-12 20:24 ` [PATCH RFC 0/4] selftests: harness: Provide global metadata pointer to allow clean teardown from selftest libraries Sean Christopherson
@ 2026-05-13 1:01 ` Kees Cook
1 sibling, 0 replies; 2+ messages in thread
From: Kees Cook @ 2026-05-13 1:01 UTC (permalink / raw)
To: Ackerley Tng
Cc: Andy Lutomirski, Will Drewry, Shuah Khan, Paolo Bonzini,
Sean Christopherson, thomas.weissschuh, linux, linux-kernel,
linux-kselftest, kvm
On Tue, Apr 14, 2026 at 11:07:47AM -0700, Ackerley Tng wrote:
> Would maintainers be open to having the kselftest harness expose a pointer
> to the metadata globally?
I would like this, yes. It's been a real pain sometimes having to pass
_metadata down into various deep helper functions.
--
Kees Cook
^ permalink raw reply [flat|nested] 2+ messages in thread