Re: [PATCH bpf v3 2/2] selftests/bpf: Add regression test for queue/stack map size limit

> diff --git a/tools/testing/selftests/bpf/prog_tests/queue_stack_map.c b/tools/testing/selftests/bpf/prog_tests/queue_stack_map.c
> index 41441325e179..043cbe92e2ba 100644
> --- a/tools/testing/selftests/bpf/prog_tests/queue_stack_map.c
> +++ b/tools/testing/selftests/bpf/prog_tests/queue_stack_map.c
> @@ -2,6 +2,8 @@
>  #include <test_progs.h>
>  #include <network_helpers.h>
>
> +#define U32_MAX ((u32)UINT_MAX)
> +

This isn't a bug, but for the single use in the test, would UINT32_MAX
(already available via <stdint.h>) work instead of adding a local
U32_MAX macro that relies on UINT_MAX coming in transitively?

> +static void test_queue_stack_map_alloc_check(void)
> +{
> +	LIBBPF_OPTS(bpf_map_create_opts, opts);

This isn't a bug, but since no field of opts is ever set in this
function, would passing NULL as the opts argument read more directly?

[ ... ]

> +	/*
> +	 * Regression test for the u32 index overflow in queue/stack maps:
> +	 * a map whose element storage (max_entries * value_size) exceeds
> +	 * U32_MAX bytes must be rejected at creation time, otherwise the
> +	 * u32 head/tail index multiplication wraps and push/peek/pop
> +	 * address the wrong element. 8192 * 1MB = 8GB > U32_MAX.
> +	 */

This isn't a bug, but could these two comments be condensed to the part
specific to the test (why 8192 x 1MB and why E2BIG), leaving the
description of the head/tail wrap to the comment the kernel patch adds
in queue_stack_maps.c?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/31396327144