From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2C8223C277F for ; Tue, 12 May 2026 20:24:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778617473; cv=none; b=qyebx7oUyhhUhSUYJwGOQMJQM8Cx7lz1qTDfdFWazFnZ43zzM5BjFZFmnMGjKermDXVVxb7OnFDQeccSKD2CxTiNiC8js7JT13poEeECE/tmWU20Sx/U4q1VAHW/x3gMEclSjDahtd7NC8PwZYWYolCUrFy1WRqe/M53yY6+ZAQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778617473; c=relaxed/simple; bh=ZuC4aqvAth3//T6/XaDMKe8783spN0RRKAEAwn3cyi8=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Rh9i8BHfX/FCOwBCQwLCf254OdSGyxU4nG7MBoDpxpOloItKB8iQ9rAQIjgxDM1cffA8yqRPpor7Jizzl0NK3oubDCyg+5DVWSKwV4yTtxc6Z7p3kOaPEcgbnH5qfb12pAiUTcp8yPdYm7f9OR/Mxd/tsy0sKPK4H+9bn6AI810= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=gwxvmmEW; arc=none smtp.client-ip=209.85.210.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="gwxvmmEW" Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-82f9f49e4beso2942226b3a.0 for ; Tue, 12 May 2026 13:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1778617471; x=1779222271; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=rokOSit4LNm5cJdb1Y3jNPDKg842KRY3HU1fgqtDryg=; b=gwxvmmEWkpugyAXCAmQfUPBKOmn+VlAfqC18V9PyxMc5SHCWn438VP+Iv9uOAKgaTw l2ri6zLHH1uFtqAB//p222/mGQonCFZSr8iIncKz+xO6UjWsRt4VOBjsizAT4TEDq28j 7bydaWzJ/yaXGmtZiQlPWktMLaydXwaPeWqOSYEcWaBGe32tcEFlXElM5R2hswbdiZZd 0Y/9ae/39n6adsG+YGmXKV8ODiwARS7X6rcObcUjgNfrrSdVzofuK/+jx+OP/g3Ojiok oXKDVp6dnHySwLYJdVkJuxYi1GB9aYdkaJpnDyTTYWtcXntX2rb2xD/wAJwtPXQPo6ij b6lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778617471; x=1779222271; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rokOSit4LNm5cJdb1Y3jNPDKg842KRY3HU1fgqtDryg=; b=ggdnb2WpCvJSMkyi3Rdr/Rmy7qd86J6z4unwxEe4DYdbY1cIcby23Yr3lWnkdR15Xr NZL2M4rvwujV3NhOZDvzMyLRZtyt7E5NCoIUvsLu7t3JInPkfKbTwon/ThXGhq4GCqP1 jBatqImhzmSoOGwKyNM9Sl2y/CYYXbWZhdEyLqLvfqQV3dtEWtfKi+xMjoOrrOdJXPU4 gdJz07CPYWeZSDzBfWFeyuu768m1VId+G7ciOJAdGpwC/F+1CngdIpbXtSvTcU7gW73f flaGQa5N0kfYeP3IfQHXf9FBh4QheJmYIhCr6rkBScqXdnpg0lEMJEQ8BH47UL0n+bch zS5w== X-Forwarded-Encrypted: i=1; AFNElJ+NlVL02j0WiJiLzhn9Xagnyxz2T65Bv8rjhiqZ2EgMeZB5Nuz6CV54YJ+6r8bZvB0lOxH7SAx8b4GE/BE=@vger.kernel.org X-Gm-Message-State: AOJu0Yz6QRGV9Hj+l2ucL4SQL3OZ77LZFwm54udt3zkPchRQ4G4iPqmv 1Mx9aX/H2ZbmaXNQiT4YP2M/ZU2ibpHYcURm1bZTYo9/0WxhchPbHJPb4vowFc7vI6TwZf4brv4 F7uyNkg== X-Received: from pfdc18.prod.google.com ([2002:aa7:8c12:0:b0:834:df9e:8e02]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:e1a:b0:82a:7893:e14b with SMTP id d2e1a72fcca58-83f042bf9c8mr170703b3a.38.1778617471299; Tue, 12 May 2026 13:24:31 -0700 (PDT) Date: Tue, 12 May 2026 13:24:30 -0700 In-Reply-To: <20260414-selftest-global-metadata-v1-0-fd223922bc57@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260414-selftest-global-metadata-v1-0-fd223922bc57@google.com> Message-ID: Subject: Re: [PATCH RFC 0/4] selftests: harness: Provide global metadata pointer to allow clean teardown from selftest libraries From: Sean Christopherson To: Ackerley Tng Cc: Kees Cook , Andy Lutomirski , Will Drewry , Shuah Khan , Paolo Bonzini , thomas.weissschuh@linutronix.de, linux@weissschuh.net, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, kvm@vger.kernel.org Content-Type: text/plain; charset="us-ascii" 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.