Re: [PATCH for-next v3 2/9] mm/slab, slub_kunit: register kprobe to trigger _nolock APIs

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Global kprobe execution introduces a data race on shared KUnit context variables, which will trigger KCSAN warnings.
- [Low] The `test_nolock()` function is conditionally compiled only when `CONFIG_PERF_EVENTS` is enabled, but it is called unconditionally by `slab_kprobe_pre_handler()` when `CONFIG_KPROBES` and `CONFIG_SMP` are enabled.
--

commit d19f8bc8e3ea86ee712ab0dede8b68fd72d0fbcf
Author: Harry Yoo (Oracle) <harry@xxxxxxxxxx>

mm/slab, slub_kunit: register kprobe to trigger _nolock APIs
    
This patch modifies the slub_kunit test to attach a kprobe pre-handler
to test the kmalloc_nolock() and kfree_nolock() APIs. It introduces a
wrapper function slab_attach_kprobe_locked() that is invoked when
slab_lockdep_assert_held() is called.

Link: https://lore.kernel.org/linux-mm/20260427-nolock-api-fix-v2-0-a6b83a92d9a4@xxxxxxxxxx [1]

> diff --git a/lib/tests/slub_kunit.c b/lib/tests/slub_kunit.c
> index 11255fc8eb781..01d808cb77faf 100644
> --- a/lib/tests/slub_kunit.c
> +++ b/lib/tests/slub_kunit.c
[ ... ]
> @@ -326,13 +334,10 @@ static struct perf_event_attr sw_attr = {
>  	.sample_freq = 100000,
>  };
>  
> -static void overflow_handler_test_nolock(struct perf_event *event,
> -					 struct perf_sample_data *data,
> -					 struct pt_regs *regs)
> +static void test_nolock(struct test_nolock_context *ctx)
>  {
>  	void *objp;
>  	gfp_t gfp;
> -	struct test_nolock_context *ctx = event->overflow_handler_context;
>  
>  	/* __GFP_ACCOUNT to test kmalloc_nolock() in alloc_slab_obj_exts() */
>  	gfp = (ctx->callback_count % 2) ? 0 : __GFP_ACCOUNT;
> @@ -347,6 +352,15 @@ static void overflow_handler_test_nolock(struct perf_event *event,
>  	ctx->callback_count++;
>  }

[ ... ]

> +#if defined(CONFIG_KPROBES) && defined(CONFIG_SMP)
> +static int slab_kprobe_pre_handler(struct kprobe *p, struct pt_regs *regs)
> +{
> +	struct test_nolock_context *ctx;
> +
> +	ctx = container_of(p, struct test_nolock_context, kprobe);
> +	test_nolock(ctx);

[Severity: Low]
If the kernel is built with CONFIG_KPROBES=y and CONFIG_SMP=y, but
CONFIG_PERF_EVENTS=n, will this result in a build failure?

The test_nolock() function is defined inside an ifdef CONFIG_PERF_EVENTS
block earlier in the file, but it is called here unconditionally when
kprobes are enabled.

[Severity: Medium]
Because slab_attach_kprobe_locked() is a global function called by SLUB
internals system-wide, could multiple CPUs hit this kprobe concurrently
during the test?

If other CPUs perform slab operations, they will trigger
slab_kprobe_pre_handler() and concurrently pass the shared kprobe_ctx to
test_nolock(). This would cause multiple threads to modify shared integers
like ctx->callback_count++, ctx->alloc_ok++, and ctx->alloc_fail++ without
atomics or locks, potentially leading to lost updates and KCSAN warnings.

> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-kfree_rcu_nolock-v3-0-70a54f3775bb@xxxxxxxxxx?part=2