From: Sean Christopherson <seanjc@google.com>
To: "Mickaël Salaün" <mic@digikod.net>
Cc: Kees Cook <keescook@chromium.org>,
Jakub Kicinski <kuba@kernel.org>,
Mark Brown <broonie@kernel.org>,
davem@davemloft.net, netdev@vger.kernel.org,
edumazet@google.com, pabeni@redhat.com, shuah@kernel.org,
linux-kselftest@vger.kernel.org,
linux-security-module@vger.kernel.org, jakub@cloudflare.com,
kvm@vger.kernel.org
Subject: Re: [PATCH v4 00/12] selftests: kselftest_harness: support using xfail
Date: Thu, 2 May 2024 11:42:29 -0700 [thread overview]
Message-ID: <ZjPelW6-AbtYvslu@google.com> (raw)
In-Reply-To: <20240305.phohPh8saa4i@digikod.net>
+kvm
On Tue, Mar 05, 2024, Mickaël Salaün wrote:
> On Tue, Mar 05, 2024 at 01:43:14AM -0800, Kees Cook wrote:
> > On Mon, Mar 04, 2024 at 03:39:02PM -0800, Jakub Kicinski wrote:
> > > On Mon, 4 Mar 2024 15:14:04 -0800 Kees Cook wrote:
> > > > > Ugh, I'm guessing vfork() "eats" the signal, IOW grandchild signals,
> > > > > child exits? vfork() and signals.. I'd rather leave to Kees || Mickael.
> > > >
> > > > Oh no, that does seem bad. Since Mickaël is also seeing weird issues,
> > > > can we drop the vfork changes for now?
> > >
> > > Seems doable, but won't be a simple revert. "drop" means we'd need
> > > to bring ->step back. More or less go back to v3.
> >
> > I think we have to -- other CIs are now showing the most of seccomp
> > failing now. (And I can confirm this now -- I had only tested seccomp
> > on earlier versions of the series.)
>
> Sorry for the trouble, I found and fixed the vfork issues.
Heh, you found and fixed _some of_ the vfork issues. This whole mess completely
breaks existing tests that use TEST_F() and exit() with non-zero values to
indicate failure, including failures that occur during FIXTURE_SETUP().
E.g. all of the KVM selftests that use KVM_ONE_VCPU_TEST() are broken and will
always show all tests as passing.
The below gets things working for KVM selftests again, but (a) I have no idea if
it's a complete fix, (b) I don't know if it will break other users of the harness,
and (c) I don't understand why spawning a grandchild is the default behavior, i.e.
why usage that has zero need of separating teardown from setup+run is subjected to
the complexity of the handful of tests that do.
diff --git a/tools/testing/selftests/kselftest_harness.h b/tools/testing/selftests/kselftest_harness.h
index 4fd735e48ee7..24e95828976f 100644
--- a/tools/testing/selftests/kselftest_harness.h
+++ b/tools/testing/selftests/kselftest_harness.h
@@ -391,7 +391,7 @@
fixture_name##_setup(_metadata, &self, variant->data); \
/* Let setup failure terminate early. */ \
if (_metadata->exit_code) \
- _exit(0); \
+ _exit(_metadata->exit_code); \
_metadata->setup_completed = true; \
fixture_name##_##test_name(_metadata, &self, variant->data); \
} else if (child < 0 || child != waitpid(child, &status, 0)) { \
@@ -406,8 +406,10 @@
} \
if (_metadata->setup_completed && _metadata->teardown_parent) \
fixture_name##_teardown(_metadata, &self, variant->data); \
- if (!WIFEXITED(status) && WIFSIGNALED(status)) \
- /* Forward signal to __wait_for_test(). */ \
+ /* Forward exit codes and signals to __wait_for_test(). */ \
+ if (WIFEXITED(status)) \
+ _exit(WEXITSTATUS(status)); \
+ else if (WIFSIGNALED(status)) \
kill(getpid(), WTERMSIG(status)); \
__test_check_assert(_metadata); \
} \
next parent reply other threads:[~2024-05-02 18:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240229005920.2407409-1-kuba@kernel.org>
[not found] ` <05f7bf89-04a5-4b65-bf59-c19456aeb1f0@sirena.org.uk>
[not found] ` <20240304150411.6a9bd50b@kernel.org>
[not found] ` <202403041512.402C08D@keescook>
[not found] ` <20240304153902.30cd2edd@kernel.org>
[not found] ` <202403050141.C8B1317C9@keescook>
[not found] ` <20240305.phohPh8saa4i@digikod.net>
2024-05-02 18:42 ` Sean Christopherson [this message]
2024-05-02 21:07 ` [PATCH v4 00/12] selftests: kselftest_harness: support using xfail Mickaël Salaün
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZjPelW6-AbtYvslu@google.com \
--to=seanjc@google.com \
--cc=broonie@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jakub@cloudflare.com \
--cc=keescook@chromium.org \
--cc=kuba@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mic@digikod.net \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).