On Tue, Feb 24, 2026 at 9:22 AM Jakub Kicinski <[email protected]> wrote: > > On Sun, 22 Feb 2026 19:18:46 +0800 Sun Jian wrote: > > XFAIL_ADD() registers expected failures using constructor order, but the > > associated struct __test_metadata pointer may not be initialized yet. > > As a result, xfail entries can end up with a NULL test pointer and never > > match at runtime, causing expected failures to be reported as FAIL. > > > > Store the test case name in the xfail entry and fall back to name-based > > matching when the test pointer is unavailable, while keeping the original > > pointer-based matching for compatibility. > > This looks a bit inelegant, what compiler is this failing on for you?
Hi Jakub, I hit this with clang + lld (LLVM=1) in a virtme-ng based net selftests run. In that setup the XFAIL_ADD() constructor runs before the corresponding _*_test_object is initialized, so xfail->test ends up NULL and we never classify XFAIL/XPASS. > Constructors seem to have a concept of priority so if we have to, > we should probably used those for the fix. I considered constructor priorities, but I'd prefer to avoid relying on toolchain/linker specific init ordering here. (The harness is userspace and we already see different behavior with clang/lld.) If you prefer a cleaner approach, I can rework this to avoid adding any new field and avoid priorities: keep xfail->test as a cached pointer, but populate it lazily at runtime on first use by looking up the test metadata by name within the fixture’s test list, then do the original pointer match. That removes the dependency on constructor ordering and keeps the matching semantics pointer-based after the first lookup. Let me know if that direction sounds better and I'll send a v2. Thanks, sun jian
