From: Nam Cao <namcao@linutronix.de>
To: wen.yang@linux.dev, Gabriele Monaco <gmonaco@redhat.com>
Cc: linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org,
Wen Yang <wen.yang@linux.dev>
Subject: Re: [PATCH v3 4/4] rv/reactors: add KUnit tests for reactor registration and dispatch
Date: Mon, 17 Aug 2026 12:52:21 +0200 [thread overview]
Message-ID: <87wltpnhne.fsf@yellow.woof> (raw)
In-Reply-To: <2b91af9f6d045f7fdb8620ef5c66c3b3e189833b.1786294920.git.wen.yang@linux.dev>
wen.yang@linux.dev writes:
> +/*
> + * Use a fixed-size array so sizeof() gives the exact byte count at
> + * compile time.
> + */
There is no need for a comment. This is obvious from the code itself.
> +static const char long_reactor_name[] = "kunit_reactor_name_too_long_xxx_";
> +_Static_assert(sizeof(long_reactor_name) - 1 >= MAX_RV_REACTOR_NAME_SIZE,
> + "long_reactor_name must be at least MAX_RV_REACTOR_NAME_SIZE chars");
> +
> +static void test_name_too_long(struct kunit *test)
> +{
> + static struct rv_reactor long_reactor = {
> + .name = long_reactor_name,
> + };
> +
> + KUNIT_EXPECT_EQ(test, rv_register_reactor(&long_reactor), -EINVAL);
> +}
> +
> +static struct kunit_case rv_reactor_registration_cases[] = {
> + KUNIT_CASE(test_double_register),
> + KUNIT_CASE(test_name_too_long),
> + {}
> +};
I am not sure about the usefulness of these test cases.
rv_register_reactor() is not an user API that we have to prepare
for corner case usage. We can expect its users to be sane since the
users are us.
But well, if Gabriele wants to keep them..
> +
> +static struct kunit_suite rv_reactor_registration_suite = {
> + .name = "rv_reactor_registration",
> + .test_cases = rv_reactor_registration_cases,
> +};
> +
> +static atomic_t react_call_count;
Do we really need atomic_t? Does int work?
> +
> +__printf(1, 0) static void mock_react(const char *msg, va_list args)
> +{
> + atomic_inc(&react_call_count);
> + /*
> + * Hold the CPU for 5 ms so a timer interrupt is likely to fire
> + * inside rv_react()'s lockdep context, exercising the LD_WAIT_SPIN
> + * constraint. mdelay() is a calibrated busy-wait with no scheduler
> + * interaction.
> + */
The comment above mdelay()'s definition already explains what it does.
> + mdelay(5);
> +}
> +
> +static void test_react_no_callback(struct kunit *test)
> +{
> + struct rv_monitor monitor = {
> + .name = "kunit_null_react",
> + };
> +
> + atomic_set(&react_call_count, 0);
> + rv_react(&monitor, "no callback");
> +
> + /*
> + * The only possible failure in this test case is a kernel panic.
> + * NULL react guard: callback must NOT have been invoked
> + */
Obvious comment.
> + KUNIT_EXPECT_EQ(test, atomic_read(&react_call_count), 0);
> +}
> +
> +static void test_react_callback_invoked(struct kunit *test)
> +{
> + struct rv_monitor monitor = {
> + .name = "kunit_dispatch_monitor",
> + .react = mock_react,
> + };
> +
> + atomic_set(&react_call_count, 0);
> + rv_react(&monitor, "callback invocation test");
> + KUNIT_EXPECT_EQ(test, atomic_read(&react_call_count), 1);
> +}
So the test calls rv_react(), and validates that the reactor is called?
Honestly I am not sure how useful that is. Especially since Gabriele
already made the selftest which validates that the reactor is invoked.
Nam
next prev parent reply other threads:[~2026-08-17 10:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-09 17:10 [PATCH v3 0/4] rv/reactors: fix lockdep warning and add KUnit tests wen.yang
2026-08-09 17:10 ` [PATCH v3 1/4] rv/reactors: use context-sensitive lockdep wait type in rv_react() wen.yang
2026-08-12 12:34 ` Gabriele Monaco
2026-08-17 8:18 ` Nam Cao
2026-08-09 17:10 ` [PATCH v3 2/4] rv/reactors: propagate rv_register_reactor() error from reactor init wen.yang
2026-08-17 10:54 ` Nam Cao
2026-08-09 17:10 ` [PATCH v3 3/4] rv/reactors: export rv_register_reactor() and rv_unregister_reactor() wen.yang
2026-08-09 17:10 ` [PATCH v3 4/4] rv/reactors: add KUnit tests for reactor registration and dispatch wen.yang
2026-08-12 12:58 ` Gabriele Monaco
2026-08-17 10:52 ` Nam Cao [this message]
2026-08-17 11:05 ` Gabriele Monaco
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=87wltpnhne.fsf@yellow.woof \
--to=namcao@linutronix.de \
--cc=gmonaco@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=wen.yang@linux.dev \
/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®