Re: [PATCH bpf 2/2] selftests/bpf: Test per-cpu initialization of a BPF_F_CPU created element

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] bpf: test inappropriately fails on uniprocessor systems instead of skipping
- [Low] bpf: multi-line comment does not follow required subsystem style
--

commit 5dd1fa65516377d52d53f05992d195284eba751e
Author: Donggeun Yoo <donggeunyoo.kernel@gmail.com>

selftests/bpf: Test per-cpu initialization of a BPF_F_CPU created element

This commit adds a subtest to verify that a BPF_F_CPU map update correctly
zeros out the value on other CPUs when creating a new element. It runs this
test against PERCPU_HASH, non-preallocated PERCPU_HASH, and LRU_PERCPU_HASH.

> diff --git a/tools/testing/selftests/bpf/prog_tests/percpu_alloc.c b/tools/testing/selftests/bpf/prog_tests/percpu_alloc.c
> index a72ae0b29f6e9..d0084a2405bed 100644
> --- a/tools/testing/selftests/bpf/prog_tests/percpu_alloc.c
> +++ b/tools/testing/selftests/bpf/prog_tests/percpu_alloc.c
> @@ -350,6 +350,74 @@ static void test_lru_percpu_hash_cpu_flag(void)
>  	test_percpu_map_cpu_flag(BPF_MAP_TYPE_LRU_PERCPU_HASH);
>  }
>  
> +/* A BPF_F_CPU update that creates an element must zero the value on the other
> + * cpus, rather than leave them holding whatever the recycled element last
> + * contained.  max_entries is 1 so the second key can only reuse the element
> + * the first one released.
> + */

[Severity: Low]
This isn't a bug, but the BPF subsystem strictly requires multi-line comments
to have the opening /* on its own line. Could this be reformatted to match
the required style?

> +static void test_percpu_map_cpu_flag_create(enum bpf_map_type map_type, __u32 map_flags)
> +{
> +	LIBBPF_OPTS(bpf_map_create_opts, opts, .map_flags = map_flags);
> +	const u32 stale = 0xDEADC0DE, fresh = 0xC0FFEE;
> +	int nr_cpus, cpu, map_fd, err, key;
> +	u32 value;
> +	u64 flags;
> +
> +	nr_cpus = libbpf_num_possible_cpus();
> +	if (!ASSERT_GT(nr_cpus, 1, "libbpf_num_possible_cpus"))
> +		return;

[Severity: Medium]
Does this force a hard failure on uniprocessor systems instead of correctly
skipping the test?

Since UP is a valid hardware configuration for running selftests, if a test
requires multiple CPUs, shouldn't it gracefully skip using test__skip()
rather than asserting a failure?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260920093153.439743-1-donggeunyoo.kernel@gmail.com?part=2