From: Guenter Roeck <linux@roeck-us.net>
To: linux-kselftest@vger.kernel.org
Cc: "David Airlie" <airlied@gmail.com>,
"Arnd Bergmann" <arnd@arndb.de>,
"Maíra Canal" <mcanal@igalia.com>,
"Dan Carpenter" <dan.carpenter@linaro.org>,
"Kees Cook" <keescook@chromium.org>,
"Daniel Diaz" <daniel.diaz@linaro.org>,
"David Gow" <davidgow@google.com>,
"Arthur Grillo" <arthurgrillo@riseup.net>,
"Brendan Higgins" <brendan.higgins@linux.dev>,
"Naresh Kamboju" <naresh.kamboju@linaro.org>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Maxime Ripard" <mripard@kernel.org>,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
loongarch@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
kunit-dev@googlegroups.com, linux-arch@vger.kernel.org,
"Guenter Roeck" <linux@roeck-us.net>
Subject: [RFC PATCH 0/5] Add support for suppressing warning backtraces
Date: Tue, 5 Mar 2024 10:40:28 -0800 [thread overview]
Message-ID: <20240305184033.425294-1-linux@roeck-us.net> (raw)
Some unit tests intentionally trigger warning backtraces by passing bad
parameters to kernel API functions. Such unit tests typically check the
return value from such calls, not the existence of the warning backtrace.
Such intentionally generated warning backtraces are neither desirable
nor useful for a number of reasons.
- They can result in overlooked real problems.
- A warning that suddenly starts to show up in unit tests needs to be
investigated and has to be marked to be ignored, for example by
adjusting filter scripts. Such filters are ad-hoc because there is
no real standard format for warnings. On top of that, such filter
scripts would require constant maintenance.
One option to address problem would be to add messages such as "expected
warning backtraces start / end here" to the kernel log. However, that
would again require filter scripts, it might result in missing real
problematic warning backtraces triggered while the test is running, and
the irrelevant backtrace(s) would still clog the kernel log.
Solve the problem by providing a means to identify and suppress specific
warning backtraces while executing test code. Support suppressing multiple
backtraces while at the same time limiting changes to generic code to the
absolute minimum. Architecture specific changes are kept at minimum by
retaining function names only if both CONFIG_DEBUG_BUGVERBOSE and
CONFIG_KUNIT are enabled.
The first patch of the series introduces the necessary infrastructure.
The second patch marks the warning message in drm_calc_scale() in the DRM
subsystem as intentional where warranted. This patch is intended to serve
as an example for the use of the functionality introduced with this series.
The last three patches in the series introduce the necessary architecture
specific changes for x86, arm64, and loongarch.
This series is based on the RFC patch and subsequent discussion at
https://patchwork.kernel.org/project/linux-kselftest/patch/02546e59-1afe-4b08-ba81-d94f3b691c9a@moroto.mountain/
and offers a more comprehensive solution of the problem discussed there.
Checkpatch note:
Remaining checkpatch errors and warnings were deliberately ignored.
Some are triggered by matching coding style or by comments interpreted
as code, others by assembler macros which are disliked by checkpatch.
Suggestions for improvements are welcome.
Some questions:
- Is the general approach promising ? If not, are there other possible
solutions ?
- Function pointers are only added to the __bug_table section if both
CONFIG_KUNIT and CONFIG_DEBUG_BUGVERBOSE are enabled. This avoids image
size increases if CONFIG_KUNIT=n. Downside is slightly more complex
architecture specific assembler code. If function pointers were always
added to the __bug_table section, vmlinux image size would increase by
approximately 0.6-0.7%. Is the increased complexity in assembler code
worth the reduced image size ? I think so, but I would like to hear
other opinions.
- There are additional possibilities associated with storing the bug
function name in the __bug_table section. It could be independent of
KUNIT, it could be a configuration flag, and/or it could be used to
display the name of the offending function in BUG/WARN messages.
Is any of those of interest ?
----------------------------------------------------------------
Guenter Roeck (5):
bug: Core support for suppressing warning backtraces
drm: Suppress intentional warning backtraces in scaling unit tests
x86: Add support for suppressing warning tracebacks
arm64: Add support for suppressing warning tracebacks
loongarch: Add support for suppressing warning tracebacks
arch/arm64/include/asm/asm-bug.h | 29 +++++++++++++-------
arch/arm64/include/asm/bug.h | 8 +++++-
arch/loongarch/include/asm/bug.h | 38 ++++++++++++++++++--------
arch/x86/include/asm/bug.h | 21 +++++++++++----
drivers/gpu/drm/tests/drm_rect_test.c | 6 +++++
include/asm-generic/bug.h | 16 ++++++++---
include/kunit/bug.h | 51 +++++++++++++++++++++++++++++++++++
include/linux/bug.h | 13 +++++++++
lib/bug.c | 51 ++++++++++++++++++++++++++++++++---
lib/kunit/Makefile | 6 +++--
lib/kunit/bug.c | 40 +++++++++++++++++++++++++++
11 files changed, 243 insertions(+), 36 deletions(-)
create mode 100644 include/kunit/bug.h
create mode 100644 lib/kunit/bug.c
next reply other threads:[~2024-03-05 18:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-05 18:40 Guenter Roeck [this message]
2024-03-05 18:40 ` [RFC PATCH 1/5] bug: Core support for suppressing warning backtraces Guenter Roeck
2024-03-05 19:54 ` Kees Cook
2024-03-05 20:17 ` Guenter Roeck
2024-03-05 18:40 ` [RFC PATCH 2/5] drm: Suppress intentional warning backtraces in scaling unit tests Guenter Roeck
2024-03-05 18:40 ` [RFC PATCH 3/5] x86: Add support for suppressing warning tracebacks Guenter Roeck
2024-03-05 18:40 ` [RFC PATCH 4/5] arm64: " Guenter Roeck
2024-03-05 18:40 ` [RFC PATCH 5/5] loongarch: " Guenter Roeck
2024-03-06 18:24 ` [RFC PATCH 0/5] Add support for suppressing warning backtraces Daniel Díaz
2024-03-06 18:57 ` Guenter Roeck
2024-03-11 4:36 ` Guenter Roeck
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=20240305184033.425294-1-linux@roeck-us.net \
--to=linux@roeck-us.net \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=arthurgrillo@riseup.net \
--cc=brendan.higgins@linux.dev \
--cc=dan.carpenter@linaro.org \
--cc=daniel.diaz@linaro.org \
--cc=daniel@ffwll.ch \
--cc=davidgow@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=keescook@chromium.org \
--cc=kunit-dev@googlegroups.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mcanal@igalia.com \
--cc=mripard@kernel.org \
--cc=naresh.kamboju@linaro.org \
--cc=tzimmermann@suse.de \
--cc=ville.syrjala@linux.intel.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).