]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
selftests/bpf: Use ASSERT_STRNEQ to factor in long slab cache names
authorMatt Bobrowski <mattbobrowski@google.com>
Tue, 18 Nov 2025 07:37:34 +0000 (07:37 +0000)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 18 Dec 2025 13:03:09 +0000 (14:03 +0100)
commit59bea0e26b8cf54b3db89e0ef0de2c90696fd5a3
treeee201d37406166ab0c07b20ac175b1cb04cf0561
parent340a73d8b6647a8e2404247cd0207337beb945c0
selftests/bpf: Use ASSERT_STRNEQ to factor in long slab cache names

[ Upstream commit d088da904223e8f5e19c6d156cf372d5baec1a7c ]

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>
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Acked-by: Song Liu <song@kernel.org>
Link: https://patch.msgid.link/20251118073734.4188710-1-mattbobrowski@google.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
tools/testing/selftests/bpf/prog_tests/kmem_cache_iter.c