[PATCH bpf-next] selftests/bpf: use ASSERT_STRNEQ to factor in long slab cache names

[PATCH bpf-next] selftests/bpf: use ASSERT_STRNEQ to factor in long slab cache names

[Matt Bobrowski]

subtest_kmem_cache_iter_check_slabinfo() fundamentally compares slab
cache names parsed out from /proc/slabinfo against those stored within
struct kmem_cache_result. The current problem is that the slab cache
name within struct kmem_cache_result is stored within a bounded
fixed-length array (sized to SLAB_NAME_MAX(32)), whereas the name
parsed out from /proc/slabinfo is not. Meaning, using ASSERT_STREQ()
can certainly lead to test failures, particularly when dealing with
slab cache names that are longer than SLAB_NAME_MAX(32)
bytes. Notably, kmem_cache_create() allows callers to create slab
caches with somewhat arbitrarily sized names via its __name identifier
argument, so exceeding the SLAB_NAME_MAX(32) limit that is in place
now can certainly happen.

Make subtest_kmem_cache_iter_check_slabinfo() more reliable by only
checking up to sizeof(struct kmem_cache_result.name) - 1 using
ASSERT_STRNEQ().

Fixes: a496d0cdc84d ("selftests/bpf: Add a test for kmem_cache_iter")
Signed-off-by: Matt Bobrowski <mattbobrowski@google.com>
---
 tools/testing/selftests/bpf/prog_tests/kmem_cache_iter.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/bpf/prog_tests/kmem_cache_iter.c b/tools/testing/selftests/bpf/prog_tests/kmem_cache_iter.c
index 1de14b111931..6e35e13c2022 100644
--- a/tools/testing/selftests/bpf/prog_tests/kmem_cache_iter.c
+++ b/tools/testing/selftests/bpf/prog_tests/kmem_cache_iter.c
@@ -57,7 +57,8 @@ static void subtest_kmem_cache_iter_check_slabinfo(struct kmem_cache_iter *skel)
 		if (!ASSERT_OK(ret, "kmem_cache_lookup"))
 			break;
 
-		ASSERT_STREQ(r.name, name, "kmem_cache_name");
+		ASSERT_STRNEQ(r.name, name, sizeof(r.name) - 1,
+			      "kmem_cache_name");
 		ASSERT_EQ(r.obj_size, objsize, "kmem_cache_objsize");
 
 		seen++;
-- 
2.52.0.rc1.455.g30608eb744-goog

Re: [PATCH bpf-next] selftests/bpf: use ASSERT_STRNEQ to factor in long slab cache names

[Song Liu]

On Mon, Nov 17, 2025 at 11:37 PM Matt Bobrowski
<mattbobrowski@google.com> wrote:
>
> subtest_kmem_cache_iter_check_slabinfo() fundamentally compares slab
> cache names parsed out from /proc/slabinfo against those stored within
> struct kmem_cache_result. The current problem is that the slab cache
> name within struct kmem_cache_result is stored within a bounded
> fixed-length array (sized to SLAB_NAME_MAX(32)), whereas the name
> parsed out from /proc/slabinfo is not. Meaning, using ASSERT_STREQ()
> can certainly lead to test failures, particularly when dealing with
> slab cache names that are longer than SLAB_NAME_MAX(32)
> bytes. Notably, kmem_cache_create() allows callers to create slab
> caches with somewhat arbitrarily sized names via its __name identifier
> argument, so exceeding the SLAB_NAME_MAX(32) limit that is in place
> now can certainly happen.
>
> Make subtest_kmem_cache_iter_check_slabinfo() more reliable by only
> checking up to sizeof(struct kmem_cache_result.name) - 1 using
> ASSERT_STRNEQ().
>
> Fixes: a496d0cdc84d ("selftests/bpf: Add a test for kmem_cache_iter")
> Signed-off-by: Matt Bobrowski <mattbobrowski@google.com>

LGTM.

Acked-by: Song Liu <song@kernel.org>

Re: [PATCH bpf-next] selftests/bpf: use ASSERT_STRNEQ to factor in long slab cache names

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to bpf/bpf-next.git (master)
by Martin KaFai Lau <martin.lau@kernel.org>:

On Tue, 18 Nov 2025 07:37:34 +0000 you wrote:
> subtest_kmem_cache_iter_check_slabinfo() fundamentally compares slab
> cache names parsed out from /proc/slabinfo against those stored within
> struct kmem_cache_result. The current problem is that the slab cache
> name within struct kmem_cache_result is stored within a bounded
> fixed-length array (sized to SLAB_NAME_MAX(32)), whereas the name
> parsed out from /proc/slabinfo is not. Meaning, using ASSERT_STREQ()
> can certainly lead to test failures, particularly when dealing with
> slab cache names that are longer than SLAB_NAME_MAX(32)
> bytes. Notably, kmem_cache_create() allows callers to create slab
> caches with somewhat arbitrarily sized names via its __name identifier
> argument, so exceeding the SLAB_NAME_MAX(32) limit that is in place
> now can certainly happen.
> 
> [...]

Here is the summary with links:
  - [bpf-next] selftests/bpf: use ASSERT_STRNEQ to factor in long slab cache names
    https://git.kernel.org/bpf/bpf-next/c/d088da904223

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html