Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Brendan Higgins <brendan.higgins@linux.dev>,
	David Gow <davidgow@google.com>,
	kunit-dev@googlegroups.com, linux-kselftest@vger.kernel.org,
	Rae Moar <rmoar@google.com>
Cc: patches@lists.linux.dev
Subject: [PATCH] kunit: tool: catch warnings generated by the kernel
Date: Fri, 18 Oct 2024 13:31:14 -0300	[thread overview]
Message-ID: <0-v1-60207444aa55+22-kunit_panic_warn_jgg@nvidia.com> (raw)

If the kunit being run generates a WARN for some reason kunit.py ignores it
and declares the tested PASSED. This is very much not desirable, as tests that
are hitting WARN's are probably actually failing.

Take the simple approach to reducing this by setting panic_on_warn when
running the kernel. The kernel crashes and kunit.py shows the WARN and reports
the test fails.

Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
 tools/testing/kunit/kunit_kernel.py | 2 ++
 1 file changed, 2 insertions(+)

I saw there was an earlier series working to make tests that deliberately made
WARNs not do that, so this would be consistent with that idea, tests should not
make WARNs, and WARNs should not be ignored..

diff --git a/tools/testing/kunit/kunit_kernel.py b/tools/testing/kunit/kunit_kernel.py
index 61931c4926fd66..7a4228568dd73c 100644
--- a/tools/testing/kunit/kunit_kernel.py
+++ b/tools/testing/kunit/kunit_kernel.py
@@ -342,6 +342,8 @@ class LinuxSourceTree:
 		if filter_action:
 			args.append('kunit.filter_action=' + filter_action)
 		args.append('kunit.enable=1')
+		args.append('panic_on_warn=1')
+		args.append('panic=-1')
 
 		process = self._ops.start(args, build_dir)
 		assert process.stdout is not None  # tell mypy it's set

base-commit: 2872987b1d009df556c0061ecdeede6a5f9bf42c
-- 
2.46.2


                 reply	other threads:[~2024-10-18 16:31 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=0-v1-60207444aa55+22-kunit_panic_warn_jgg@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=brendan.higgins@linux.dev \
    --cc=davidgow@google.com \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=rmoar@google.com \
    /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