From: Brendan Jackman <jackmanb@google.com>
To: "Thomas Weißschuh" <thomas.weissschuh@linutronix.de>,
"Shuah Khan" <shuah@kernel.org>,
"Brendan Jackman" <jackmanb@google.com>
Cc: Shuah Khan <skhan@linuxfoundation.org>,
<linux-kselftest@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] selftests: runner: Avoid spurious warning about missing failures file
Date: Wed, 28 Jan 2026 11:18:35 +0000 [thread overview]
Message-ID: <DG06J6S40UW7.15VFU5DA8YJIY@google.com> (raw)
In-Reply-To: <20260128-kselftest-fix-failures-file-v1-1-b58072c66317@linutronix.de>
On Wed Jan 28, 2026 at 9:05 AM UTC, Thomas Weißschuh wrote:
> When runner.sh is *not* executed via run_kselftest.sh,
Hm, what's the usecase for that? runner.sh is a "library", right? So in
my mind there's basically an undocumented contract that you need to set
this variable before you call the relevant functions.
The fix below opens the door to bugs where we fail to report test
failures which would be... a shame!
> the variable
> $kselftest_failures_file does not exist. This triggers a harmless but
> annyoing warning from runner.sh if a test fails:
>
> tools/testing/selftests/kselftest/runner.sh: line 50: : No such file or directory
>
> Silence the spurious warning.
>
> Fixes: d9e6269e3303 ("selftests/run_kselftest.sh: exit with error if tests fail")
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Having said that, it's not a big deal, the risk of those bugs is not
that high and we'd probably notice them before too long. Assuming you
have a usecase where just setting the variable to /dev/null yourself is
a pain, this LGTM.
Reviewed-By: Brendan Jackman <jackmanb@google.com>
next prev parent reply other threads:[~2026-01-28 11:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-28 9:05 Thomas Weißschuh
2026-01-28 11:18 ` Brendan Jackman [this message]
2026-01-28 11:39 ` Thomas Weißschuh
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=DG06J6S40UW7.15VFU5DA8YJIY@google.com \
--to=jackmanb@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=thomas.weissschuh@linutronix.de \
/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
all inboxes | Powered by JetHome®