From: sashiko-bot@kernel.org
To: "Harry Yoo (Oracle)" <harry@kernel.org>
Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rt-devel@lists.linux.dev
Subject: Re: [PATCH v5 8/8] slub_kunit: extend the test for kfree_rcu_nolock()
Date: Wed, 29 Jul 2026 08:39:44 +0000 [thread overview]
Message-ID: <20260729083944.B0F2C1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260729-kfree_rcu_nolock-v5-8-a28cdcda9673@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing synchronization for deferred RCU frees causes KUnit test suite contamination and false negatives.
--
--- Patch [8]: [PATCH v5 8/8] slub_kunit: extend the test for kfree_rcu_nolock() ---
commit 975207c355ab3b2db3420df72699cb12e4769b5e
Author: Harry Yoo (Oracle) <harry@kernel.org>
slub_kunit: extend the test for kfree_rcu_nolock()
When slub_kunit is not built-in, call kfree_rcu() and kfree_rcu_nolock()
to test kfree_rcu_nolock() in slub_kunit.
Rename the test case as the test covers more _nolock() APIs.
> diff --git a/lib/tests/slub_kunit.c b/lib/tests/slub_kunit.c
> index 8c2b9911471eb..e3b63f0338d5f 100644
> --- a/lib/tests/slub_kunit.c
> +++ b/lib/tests/slub_kunit.c
[ ... ]
> @@ -397,14 +410,14 @@ static void disable_perf_events(struct test_nolock_context *ctx)
> perf_event_release_kernel(ctx->event);
> }
>
> -static void test_kmalloc_kfree_nolock_perf(struct kunit *test)
> +static void test_kmalloc_nolock_and_friends_perf(struct kunit *test)
> {
> struct test_nolock_context ctx = { .test = test };
>
> if (!enable_perf_events(&ctx))
> kunit_skip(test, "Failed to enable perf event, skipping");
>
> - test_kmalloc_kfree();
> + test_kmalloc_and_friends();
>
> disable_perf_events(&ctx);
> KUNIT_EXPECT_EQ(test, 0, slab_errors);
[Severity: Medium]
Will this evaluate slab_errors before all asynchronous frees complete?
Since test_kmalloc_and_friends() queues objects via kfree_rcu() and
kfree_rcu_nolock(), the callbacks could execute in softirq context later.
If they interrupt a subsequent KUnit test, slab_add_kunit_errors() could
attribute any SLUB errors from these deferred frees to the next test, causing
it to falsely fail while causing this test to falsely pass.
Should we add a synchronization call like kvfree_rcu_barrier() before
checking slab_errors?
[ ... ]
> @@ -438,14 +451,14 @@ static void unregister_slab_kprobes(struct test_nolock_context *ctx)
> unregister_kprobe(&ctx->kprobe);
> }
>
> -static void test_kmalloc_kfree_nolock_kprobe(struct kunit *test)
> +static void test_kmalloc_nolock_and_friends_kprobe(struct kunit *test)
> {
> struct test_nolock_context ctx = { .test = test };
>
> if (!register_slab_kprobes(&ctx))
> kunit_skip(test, "Failed to register kprobe, skipping");
>
> - test_kmalloc_kfree();
> + test_kmalloc_and_friends();
>
> unregister_slab_kprobes(&ctx);
> KUNIT_EXPECT_EQ(test, 0, slab_errors);
[Severity: Medium]
Does this test case need synchronization for the same reason?
Without a barrier before evaluating slab_errors, deferred RCU frees from
test_kmalloc_and_friends() might leak into the next KUnit test and cause
false test failures.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260729-kfree_rcu_nolock-v5-0-a28cdcda9673@kernel.org?part=8
next prev parent reply other threads:[~2026-07-29 8:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 8:20 [PATCH v5 0/8] mm/slab: introduce kfree_rcu_nolock() and improve slub_kunit coverage Harry Yoo (Oracle)
2026-07-29 8:20 ` [PATCH v5 1/8] mm/slab, slub_kunit: register kprobe to trigger _nolock APIs Harry Yoo (Oracle)
2026-07-29 8:35 ` sashiko-bot
2026-07-29 8:20 ` [PATCH v5 2/8] mm/slab: handle the !allow_spin case in kfree_rcu_sheaf() Harry Yoo (Oracle)
2026-07-29 8:44 ` sashiko-bot
2026-07-29 8:20 ` [PATCH v5 3/8] mm/slab: use call_rcu() in unknown context if irqs are enabled Harry Yoo (Oracle)
2026-07-29 8:47 ` sashiko-bot
2026-07-29 8:20 ` [PATCH v5 4/8] mm/slab: extend deferred free mechanism to handle rcu sheaves Harry Yoo (Oracle)
2026-07-29 8:20 ` [PATCH v5 5/8] mm/slab: allow kfree_rcu_sheaf() on PREEMPT_RT Harry Yoo (Oracle)
2026-07-29 8:43 ` sashiko-bot
2026-07-29 8:20 ` [PATCH v5 6/8] mm/slab: introduce struct kvfree_rcu_head for kvfree_rcu batching Harry Yoo (Oracle)
2026-07-29 8:40 ` sashiko-bot
2026-07-29 8:20 ` [PATCH v5 7/8] mm/slab: introduce kfree_rcu_nolock() Harry Yoo (Oracle)
2026-07-29 8:41 ` sashiko-bot
2026-07-29 8:20 ` [PATCH v5 8/8] slub_kunit: extend the test for kfree_rcu_nolock() Harry Yoo (Oracle)
2026-07-29 8:39 ` sashiko-bot [this message]
2026-07-29 14:14 ` [PATCH v5 0/8] mm/slab: introduce kfree_rcu_nolock() and improve slub_kunit coverage Vlastimil Babka (SUSE)
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=20260729083944.B0F2C1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=harry@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.