From: sashiko-bot@kernel.org
To: "Jinchao Wang" <wangjinchao600@gmail.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [RFC PATCH 12/13] mm/kwatch: add KUnit tests for the watch expression parser
Date: Tue, 14 Jul 2026 18:50:09 +0000 [thread overview]
Message-ID: <20260714185009.DE0561F00ACF@smtp.kernel.org> (raw)
In-Reply-To: <20260714183339.13044-1-wangjinchao600@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Hardcoded 64-bit absolute address in the KUnit test will cause compilation warnings and guaranteed runtime failures on 32-bit platforms.
- [Medium] KUnit test cannot be enabled when KWatch is a loadable module, and fixing the Kconfig exposes a multiple `module_init` build failure.
--
--- Patch [12]: [RFC PATCH 12/13] mm/kwatch: add KUnit tests for the watch expression parser ---
commit 5eda6d9ba13c286416e92d504d097afadcc1400d
Author: Jinchao Wang <wangjinchao600@gmail.com>
mm/kwatch: add KUnit tests for the watch expression parser
This commit adds a KUnit test suite for the KWatch expression parser. It
covers base anchors, offsets, dereference chains, and rejection of malformed
expressions.
> diff --git a/mm/kwatch/Kconfig b/mm/kwatch/Kconfig
> index b1c37a829dd53..74083040a1a33 100644
> --- a/mm/kwatch/Kconfig
> +++ b/mm/kwatch/Kconfig
> @@ -15,3 +15,13 @@ config KWATCH
> exact instruction causing the illegal access.
>
> If unsure, say N.
> +
> +config KWATCH_KUNIT_TEST
> + bool "KUnit tests for KWatch" if !KUNIT_ALL_TESTS
> + depends on KWATCH && KUNIT
[Severity: Medium]
Will this test be silently disabled when KWATCH is built as a loadable module?
Because CONFIG_KWATCH_KUNIT_TEST is a bool, if KWATCH is configured as a
module ('m'), the dependency expression evaluates to 'm' and Kconfig will
automatically downgrade the boolean's visibility to 'n', making it impossible
to run the test suite for module builds.
> + default KUNIT_ALL_TESTS
> + help
> + Enable KUnit tests for the KWatch kernel module.
[ ... ]
> diff --git a/mm/kwatch/deref_test.c b/mm/kwatch/deref_test.c
> new file mode 100644
> index 0000000000000..094b7afeb235e
> --- /dev/null
> +++ b/mm/kwatch/deref_test.c
> @@ -0,0 +1,137 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <kunit/test.h>
> +#include "kwatch.h"
> +#include <linux/string.h>
> +
> +static void kwatch_test_parse_deref_chain(struct kunit *test)
> +{
> + struct kwatch_config cfg;
> + int ret;
[ ... ]
> + // Test 13: Absolute address
> + memset(&cfg, 0, sizeof(cfg));
> + ret = kwatch_deref_parse(&cfg, "0xffffffff81000000+8");
[Severity: High]
Will this hardcoded 64-bit address cause failures on 32-bit platforms?
On 32-bit architectures, this string will exceed ULONG_MAX, causing
the internal kstrtoul() to safely fail and return -ERANGE. The parser
will then fall back to treating it as a global symbol name via
kallsyms_lookup_name(), which will also fail, ultimately returning -EINVAL
and breaking the test logic.
> + KUNIT_EXPECT_EQ(test, ret, 0);
> + KUNIT_EXPECT_EQ(test, cfg.base, KWATCH_BASE_ABS_ADDR);
> + KUNIT_EXPECT_EQ(test, cfg.sym_addr, 0xffffffff81000000UL);
[Severity: High]
Does this 64-bit literal cause implicit truncation compiler warnings
and test comparison failures on 32-bit architectures where unsigned long
is only 32 bits?
> + KUNIT_EXPECT_EQ(test, cfg.offset_count, 1);
> + KUNIT_EXPECT_EQ(test, cfg.offsets[0], 8);
> +}
> +
> +static struct kunit_case kwatch_deref_test_cases[] = {
> + KUNIT_CASE(kwatch_test_parse_deref_chain),
> + {}
> +};
> +
> +static struct kunit_suite kwatch_deref_test_suite = {
> + .name = "kwatch_deref",
> + .test_cases = kwatch_deref_test_cases,
> +};
> +
> +kunit_test_suite(kwatch_deref_test_suite);
[Severity: Medium]
If the Kconfig dependency above is fixed to allow this test to run with module
builds (e.g., depends on KWATCH != n), will this cause a multiple definition
build failure?
Since deref_test.o is linked directly into the kwatch module in the Makefile,
and kunit_test_suite() emits a module_init() alias, this will conflict with
the primary module_init() definition that likely already exists for kwatch.
> +
> +MODULE_DESCRIPTION("KUnit tests for the KWatch watch expression parser");
> +MODULE_LICENSE("GPL");
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260714182243.10687-1-wangjinchao600@gmail.com?part=12
next prev parent reply other threads:[~2026-07-14 18:50 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 18:22 [RFC PATCH 00/13] mm/kwatch: dynamic hardware watchpoints for hunting memory corruption Jinchao Wang
2026-07-14 18:22 ` [RFC PATCH 01/13] arch: add HAVE_REINSTALL_HW_BREAKPOINT Jinchao Wang
2026-07-14 18:22 ` [RFC PATCH 02/13] x86/hw_breakpoint: Unify breakpoint install/uninstall Jinchao Wang
2026-07-14 18:47 ` sashiko-bot
2026-07-14 18:22 ` [RFC PATCH 03/13] x86/hw_breakpoint: Add arch_reinstall_hw_breakpoint Jinchao Wang
2026-07-14 19:22 ` sashiko-bot
2026-07-14 18:30 ` [RFC PATCH 04/13] HWBP: Add modify_wide_hw_breakpoint_local() API Jinchao Wang
2026-07-14 19:41 ` sashiko-bot
2026-07-14 18:31 ` [RFC PATCH 05/13] mm/kwatch: add watch expression parser and dereference engine Jinchao Wang
2026-07-14 18:45 ` sashiko-bot
2026-07-14 18:31 ` [RFC PATCH 06/13] mm/kwatch: add lockless per-task context pool Jinchao Wang
2026-07-14 18:44 ` sashiko-bot
2026-07-14 18:31 ` [RFC PATCH 07/13] stacktrace: export stack_trace_save_regs() Jinchao Wang
2026-07-14 18:42 ` sashiko-bot
2026-07-14 18:32 ` [RFC PATCH 08/13] mm/kwatch: add hardware breakpoint backend Jinchao Wang
2026-07-14 18:50 ` sashiko-bot
2026-07-14 21:14 ` Steven Rostedt
2026-07-14 18:32 ` [RFC PATCH 09/13] mm/kwatch: add probe lifecycle runtime Jinchao Wang
2026-07-14 19:53 ` sashiko-bot
2026-07-14 18:32 ` [RFC PATCH 10/13] mm/kwatch: add anchor thread for global watchpoints Jinchao Wang
2026-07-14 18:48 ` sashiko-bot
2026-07-14 18:33 ` [RFC PATCH 11/13] mm/kwatch: add debugfs control plane Jinchao Wang
2026-07-14 18:58 ` sashiko-bot
2026-07-14 18:33 ` [RFC PATCH 12/13] mm/kwatch: add KUnit tests for the watch expression parser Jinchao Wang
2026-07-14 18:50 ` sashiko-bot [this message]
2026-07-14 18:33 ` [RFC PATCH 13/13] Documentation/dev-tools: document KWatch Jinchao Wang
2026-07-14 18:48 ` sashiko-bot
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=20260714185009.DE0561F00ACF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=wangjinchao600@gmail.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