From: sashiko-bot@kernel.org
Cc: linux-rt-devel@lists.linux.dev, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH for-next v3 1/9] slub_kunit: fall back to SW perf events when HW PMU is not available
Date: Mon, 15 Jun 2026 11:14:34 +0000 [thread overview]
Message-ID: <20260615111434.802AD1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260615-kfree_rcu_nolock-v3-1-70a54f3775bb@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The test cleanup function reads and logs test context variables before disabling the asynchronous perf event, introducing a data race and causing the reported counts to be inaccurate.
--
commit 4fccf2c0f65ae8a2788eab369ec35d223d9c897d
Author: Harry Yoo (Oracle) <harry@kernel.org>
slub_kunit: fall back to SW perf events when HW PMU is not available
This commit introduces a fallback mechanism in the slub_kunit tests to use
software perf events when a hardware PMU is unavailable. This ensures the
tests can still execute in virtualized environments that lack virtual PMUs.
> diff --git a/lib/tests/slub_kunit.c b/lib/tests/slub_kunit.c
> --- a/lib/tests/slub_kunit.c
> +++ b/lib/tests/slub_kunit.c
[ ... ]
> +static void disable_perf_events(struct test_nolock_context *ctx)
> +{
> + kunit_info(ctx->test, "%s perf events: callback_count: %d, alloc_ok: %d, alloc_fail: %d\n",
> + ctx->is_perf_type_hw ? "HW" : "SW",
> + ctx->callback_count, ctx->alloc_ok, ctx->alloc_fail);
> +
> + perf_event_disable(ctx->event);
[Severity: Medium]
Could reading the counters before disabling the perf event result in missed
counts?
Since the perf event continues to fire asynchronously in NMI or IRQ context
until perf_event_disable() is called, the variables might be incremented
after kunit_info() has already read them.
Would it be safer to disable the perf event before reading and logging the
results, restoring the original ordering from the previous cleanup block?
> + perf_event_release_kernel(ctx->event);
> +}
[ ... ]
> @@ -368,11 +412,7 @@ static void test_kmalloc_kfree_nolock(struct kunit *test)
> }
>
> cleanup:
> - perf_event_disable(ctx.event);
> - perf_event_release_kernel(ctx.event);
> -
> - kunit_info(test, "callback_count: %d, alloc_ok: %d, alloc_fail: %d\n",
> - ctx.callback_count, ctx.alloc_ok, ctx.alloc_fail);
> + disable_perf_events(&ctx);
>
> if (alloc_fail)
> kunit_skip(test, "Allocation failed");
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-kfree_rcu_nolock-v3-0-70a54f3775bb@kernel.org?part=1
next prev parent reply other threads:[~2026-06-15 11:14 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-15 11:05 [PATCH for-next v3 0/9] mm/slab: introduce kfree_rcu_nolock() and improve slub_kunit coverage Harry Yoo (Oracle)
2026-06-15 11:05 ` [PATCH for-next v3 1/9] slub_kunit: fall back to SW perf events when HW PMU is not available Harry Yoo (Oracle)
2026-06-15 11:14 ` sashiko-bot [this message]
2026-06-15 12:58 ` Harry Yoo
2026-06-15 20:01 ` Alexei Starovoitov
2026-06-15 11:05 ` [PATCH for-next v3 2/9] mm/slab, slub_kunit: register kprobe to trigger _nolock APIs Harry Yoo (Oracle)
2026-06-15 11:25 ` sashiko-bot
2026-06-15 20:04 ` Alexei Starovoitov
2026-06-15 11:05 ` [PATCH for-next v3 3/9] mm/slab: handle the !allow_spin case in kfree_rcu_sheaf() Harry Yoo (Oracle)
2026-06-15 11:24 ` sashiko-bot
2026-06-15 11:05 ` [PATCH for-next v3 4/9] mm/slab: use call_rcu() in unknown context if irqs are enabled Harry Yoo (Oracle)
2026-06-15 11:25 ` sashiko-bot
2026-06-15 11:05 ` [PATCH for-next v3 5/9] mm/slab: extend deferred free mechanism to handle rcu sheaves Harry Yoo (Oracle)
2026-06-15 11:24 ` sashiko-bot
2026-06-15 11:06 ` [PATCH for-next v3 6/9] mm/slab: allow kfree_rcu_sheaf() on PREEMPT_RT Harry Yoo (Oracle)
2026-06-15 11:19 ` sashiko-bot
2026-06-15 11:06 ` [PATCH for-next v3 7/9] mm/slab: introduce kfree_rcu_nolock() Harry Yoo (Oracle)
2026-06-15 11:22 ` sashiko-bot
2026-06-15 11:06 ` [PATCH for-next v3 8/9] mm/slab: introduce struct kfree_rcu_head and use in kfree_rcu_nolock() Harry Yoo (Oracle)
2026-06-15 11:22 ` sashiko-bot
2026-06-15 11:06 ` [PATCH for-next v3 9/9] slub_kunit: extend the test for kfree_rcu_nolock() Harry Yoo (Oracle)
2026-06-15 11:43 ` [PATCH for-next v3 0/9] mm/slab: introduce kfree_rcu_nolock() and improve slub_kunit coverage Harry Yoo
2026-06-15 20:28 ` Alexei Starovoitov
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=20260615111434.802AD1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=sashiko-reviews@lists.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.