Re: [PATCH bpf-next 4/4] selftests/bpf: Add tests for arena slub-backed allocator

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `arena_slab_freeptr_stale_pcs` selftest will reliably fail on architectures with a page size larger than 4K (e.g., ARM64 with 64K pages) due to hardcoded assumptions about SLUB slab page capacities.
--

commit 307042b1f4f8cca55cad67f2c12869bf67a9f7c2
Author: Alexei Starovoitov <ast@kernel.org>

selftests/bpf: Add tests for arena slub-backed allocator

This commit adds end-to-end selftests covering the SLAB_BPF_ARENA path.
It includes smoke tests for basic alloc/free kfuncs and exercises corrupted
in-object freepointers to validate get_freepointer() clamping.

> diff --git a/tools/testing/selftests/bpf/progs/arena_slab_freeptr_stale_pcs.c b/tools/testing/selftests/bpf/progs/arena_slab_freeptr_stale_pcs.c
> new file mode 100644
> index 0000000000000..4d23d75419d61
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/arena_slab_freeptr_stale_pcs.c

[ ... ]

> +	victim = objs[TARGET_IDX];
> +
> +	/*
> +	 * The 4096-byte bucket has one object per slab and a 4-object sheaf.
> +	 * Free @victim while the sheaf is full, then turn its encoded NULL
> +	 * freepointer into any non-NULL decoded value. The arena clamp keeps
> +	 * non-NULL decoded values in the same slab and object-aligned, so this
> +	 * becomes a freelist self-cycle back to @victim.
> +	 */

[Severity: Medium]
Is this assumption valid on architectures with page sizes larger than 4K?

On a system with 64KB pages, a 4096-byte bucket would hold multiple objects
per slab page instead of just one.

[ ... ]

> +	/*
> +	 * The sheaf is full of duplicate victim pointers now. Free the four
> +	 * filler objects plus one extra object directly to SLUB, leaving enough
> +	 * partial slabs that the next target-slab zero-inuse transition discards
> +	 * the target page instead of keeping it on the partial list.
> +	 */
> +	for (i = 0; i < SHEAF_FILL; i++)
> +		bpf_arena_free(&arena, objs[i]);
> +	bpf_arena_free(&arena, objs[EXTRA_IDX]);
> +
> +	bpf_arena_free(&arena, victim);
> +
> +	p = bpf_arena_alloc(&arena, OBJ_SIZE);
> +	if (!p)
> +		stale_alloc_null = 1;

[Severity: Medium]
Will this logic successfully discard the target page on architectures like
arm64 configured with 64K pages?

Since 64KB pages can hold multiple 4096-byte objects, all these allocations
might be placed into the exact same order-0 slab page. Freeing the filler
objects would merely drop the inuse count of that single slab page rather
than creating multiple empty slab pages to fill the partial list.

When the victim object is freed, wouldn't SLUB retain the page instead of
returning it to the OS, causing the final allocation to succeed and
stale_alloc_null to remain 0, thus failing the test?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260529202438.16408-1-alexei.starovoitov@gmail.com?part=4