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.
