From: David Gow <david@davidgow.net>
To: Albert Esteve <aesteve@redhat.com>, Arnd Bergmann <arnd@arndb.de>,
Brendan Higgins <brendan.higgins@linux.dev>,
Rae Moar <raemoar63@gmail.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com,
dri-devel@lists.freedesktop.org, workflows@vger.kernel.org,
linux-doc@vger.kernel.org, peterz@infradead.org,
Guenter Roeck <linux@roeck-us.net>,
Linux Kernel Functional Testing <lkft@linaro.org>,
Dan Carpenter <dan.carpenter@linaro.org>,
Alessandro Carminati <acarmina@redhat.com>,
Kees Cook <kees@kernel.org>
Subject: Re: [PATCH v7 3/5] kunit: Add backtrace suppression self-tests
Date: Wed, 22 Apr 2026 20:20:04 +0800 [thread overview]
Message-ID: <6209f24e-750d-4a7d-ad63-1695f5fd1caa@davidgow.net> (raw)
In-Reply-To: <20260420-kunit_add_support-v7-3-e8bc6e0f70de@redhat.com>
Le 20/04/2026 à 8:28 PM, Albert Esteve a écrit :
> From: Guenter Roeck <linux@roeck-us.net>
>
> Add unit tests to verify that warning backtrace suppression works,
> covering WARN() and WARN_ON() with direct calls, indirect calls
> through helper functions, and multiple warnings in a single window.
>
> If backtrace suppression does _not_ work, the unit tests will likely
> trigger unsuppressed backtraces, which should actually help to get
> the affected architectures / platforms fixed.
>
> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
> Acked-by: Dan Carpenter <dan.carpenter@linaro.org>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
> Signed-off-by: Albert Esteve <aesteve@redhat.com>
> ---
Thanks very much for including tests!
Maybe it'd be nice to test that the suppression is disabled after
KUNIT_END_SUPPRESSED_WARNING(). Of course, then triggering an actual
stacktrace would be a pain, but maybe we could check that
__kunit_is_suppressed_warning() returns false? If you wanted to be
really fancy, you could test that it returns false on another kthread
even while the suppression is active, too, but I won't hold you to it.
Equally, you could try setting up a fake test context and ensuring the
cleanup is called correctly, but I think that's mostly covered by the
existing KUnit resource tests.
Otherwise, looking good. A couple of other minor suggestions below,
which may require some reworking of the __kunit_suppress scope, but all
optional suggestions.
Reviewed-by: David Gow <david@davidgow.net>
> lib/kunit/Makefile | 3 ++
> lib/kunit/backtrace-suppression-test.c | 90 ++++++++++++++++++++++++++++++++++
> 2 files changed, 93 insertions(+)
>
> diff --git a/lib/kunit/Makefile b/lib/kunit/Makefile
> index fe177ff3ebdef..b2f2b8ada7b71 100644
> --- a/lib/kunit/Makefile
> +++ b/lib/kunit/Makefile
> @@ -23,6 +23,9 @@ obj-$(if $(CONFIG_KUNIT),y) += hooks.o \
>
> obj-$(CONFIG_KUNIT_TEST) += kunit-test.o
> obj-$(CONFIG_KUNIT_TEST) += platform-test.o
> +ifeq ($(CONFIG_KUNIT_SUPPRESS_BACKTRACE),y)
> +obj-$(CONFIG_KUNIT_TEST) += backtrace-suppression-test.o
> +endif
>
> # string-stream-test compiles built-in only.
> ifeq ($(CONFIG_KUNIT_TEST),y)
> diff --git a/lib/kunit/backtrace-suppression-test.c b/lib/kunit/backtrace-suppression-test.c
> new file mode 100644
> index 0000000000000..2ba5dcb5fef35
> --- /dev/null
> +++ b/lib/kunit/backtrace-suppression-test.c
> @@ -0,0 +1,90 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * KUnit test for suppressing warning tracebacks.
> + *
> + * Copyright (C) 2024, Guenter Roeck
> + * Author: Guenter Roeck <linux@roeck-us.net>
> + */
> +
> +#include <kunit/test.h>
> +#include <linux/bug.h>
> +
> +static void backtrace_suppression_test_warn_direct(struct kunit *test)
> +{
> + KUNIT_START_SUPPRESSED_WARNING(test);
> + WARN(1, "This backtrace should be suppressed");
> + KUNIT_END_SUPPRESSED_WARNING(test);
> +
> + KUNIT_EXPECT_EQ(test, KUNIT_SUPPRESSED_WARNING_COUNT(), 1);
> +}
> +
> +static void trigger_backtrace_warn(void)
> +{
> + WARN(1, "This backtrace should be suppressed");
> +}
> +
> +static void backtrace_suppression_test_warn_indirect(struct kunit *test)
> +{
> + KUNIT_START_SUPPRESSED_WARNING(test);
> + trigger_backtrace_warn();
> + KUNIT_END_SUPPRESSED_WARNING(test);
> +
> + KUNIT_EXPECT_EQ(test, KUNIT_SUPPRESSED_WARNING_COUNT(), 1);
> +}
> +
> +static void backtrace_suppression_test_warn_multi(struct kunit *test)
> +{
> + KUNIT_START_SUPPRESSED_WARNING(test);
> + WARN(1, "This backtrace should be suppressed");
> + trigger_backtrace_warn();
> + KUNIT_END_SUPPRESSED_WARNING(test);
> +
> + KUNIT_EXPECT_EQ(test, KUNIT_SUPPRESSED_WARNING_COUNT(), 2);
Would it make sense to test KUNIT_SUPPRESSED_WARNING_COUNT() more
thoroughly here by checking that it's 0 before any warnings, and
checking that it's 1 in-between the two warnings?
Of course, the first case doesn't work due to __kunit_suppress not being
defined, but if the implementation changes to support this, let's add it
to the test, too.
> +}
> +
> +static void backtrace_suppression_test_warn_on_direct(struct kunit *test)
> +{
> + if (!IS_ENABLED(CONFIG_DEBUG_BUGVERBOSE) && !IS_ENABLED(CONFIG_KALLSYMS))
> + kunit_skip(test, "requires CONFIG_DEBUG_BUGVERBOSE or CONFIG_KALLSYMS");
> +
> + KUNIT_START_SUPPRESSED_WARNING(test);
> + WARN_ON(1);
> + KUNIT_END_SUPPRESSED_WARNING(test);
> +
> + KUNIT_EXPECT_EQ(test, KUNIT_SUPPRESSED_WARNING_COUNT(), 1);
> +}
> +
> +static void trigger_backtrace_warn_on(void)
> +{
> + WARN_ON(1);
> +}
> +
> +static void backtrace_suppression_test_warn_on_indirect(struct kunit *test)
> +{
> + if (!IS_ENABLED(CONFIG_DEBUG_BUGVERBOSE))
> + kunit_skip(test, "requires CONFIG_DEBUG_BUGVERBOSE");
> +
> + KUNIT_START_SUPPRESSED_WARNING(test);
> + trigger_backtrace_warn_on();
> + KUNIT_END_SUPPRESSED_WARNING(test);
> +
> + KUNIT_EXPECT_EQ(test, KUNIT_SUPPRESSED_WARNING_COUNT(), 1);
> +}
> +
> +static struct kunit_case backtrace_suppression_test_cases[] = {
> + KUNIT_CASE(backtrace_suppression_test_warn_direct),
> + KUNIT_CASE(backtrace_suppression_test_warn_indirect),
> + KUNIT_CASE(backtrace_suppression_test_warn_multi),
> + KUNIT_CASE(backtrace_suppression_test_warn_on_direct),
> + KUNIT_CASE(backtrace_suppression_test_warn_on_indirect),
> + {}
> +};
> +
> +static struct kunit_suite backtrace_suppression_test_suite = {
> + .name = "backtrace-suppression-test",
> + .test_cases = backtrace_suppression_test_cases,
> +};
> +kunit_test_suites(&backtrace_suppression_test_suite);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("KUnit test to verify warning backtrace suppression");
>
next prev parent reply other threads:[~2026-04-22 12:22 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-20 12:28 [PATCH v7 0/5] kunit: Add support for suppressing warning backtraces Albert Esteve
2026-04-20 12:28 ` [PATCH v7 1/5] bug/kunit: Core " Albert Esteve
2026-04-20 14:39 ` Peter Zijlstra
2026-04-21 8:22 ` Albert Esteve
2026-04-20 14:45 ` Peter Zijlstra
2026-04-21 8:29 ` Albert Esteve
2026-04-22 12:19 ` David Gow
2026-04-20 12:28 ` [PATCH v7 2/5] bug/kunit: Reduce runtime impact of warning backtrace suppression Albert Esteve
2026-04-20 14:44 ` Peter Zijlstra
2026-04-21 8:41 ` Albert Esteve
2026-04-22 12:19 ` David Gow
2026-04-20 12:28 ` [PATCH v7 3/5] kunit: Add backtrace suppression self-tests Albert Esteve
2026-04-22 12:20 ` David Gow [this message]
2026-04-20 12:28 ` [PATCH v7 4/5] drm: Suppress intentional warning backtraces in scaling unit tests Albert Esteve
2026-04-20 14:47 ` Peter Zijlstra
2026-04-21 8:49 ` Albert Esteve
2026-04-21 11:50 ` Jani Nikula
2026-04-22 12:20 ` David Gow
2026-04-20 12:28 ` [PATCH v7 5/5] kunit: Add documentation for warning backtrace suppression API Albert Esteve
2026-04-22 12:20 ` David Gow
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=6209f24e-750d-4a7d-ad63-1695f5fd1caa@davidgow.net \
--to=david@davidgow.net \
--cc=acarmina@redhat.com \
--cc=aesteve@redhat.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=brendan.higgins@linux.dev \
--cc=corbet@lwn.net \
--cc=dan.carpenter@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=kees@kernel.org \
--cc=kunit-dev@googlegroups.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lkft@linaro.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=peterz@infradead.org \
--cc=raemoar63@gmail.com \
--cc=simona@ffwll.ch \
--cc=skhan@linuxfoundation.org \
--cc=tzimmermann@suse.de \
--cc=workflows@vger.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