Re: [PATCH bpf-next v14 8/8] selftests/bpf: Add tests to verify map create failure log

[Leon Hwang <leon.hwang@linux.dev>]

On 2026/5/14 09:25, sashiko-bot@kernel.org wrote:
[...]
>> +static void test_invalid_numa_node(void)
>> +{
>> +	const char *msg = "Invalid numa_node.\n";
>> +	LIBBPF_OPTS(bpf_map_create_opts, opts,
>> +		    .map_flags = BPF_F_NUMA_NODE,
>> +		    .numa_node = 0xFF,
> 
> Would this test be flaky on a massive system? Using 0xFF (255) for the
> NUMA node could accidentally match an online node on systems with large NUMA
> topologies (e.g., up to 1024 nodes).
> 
> Would it be safer to use ~0U or -1 to represent a guaranteed invalid node?
> 
>> +	);
>> +
>> +	test_map_create_array(&opts, msg);
>> +}
> [ ... ]
>> +static void test_invalid_token_fd(void)
>> +{
>> +	const char *msg = "Invalid map_token_fd.\n";
>> +	LIBBPF_OPTS(bpf_map_create_opts, opts,
>> +		    .map_flags = BPF_F_TOKEN_FD,
>> +		    .token_fd = 0xFF,
> 
> Could the use of 0xFF (255) as a file descriptor lead to spurious test failures?
> 
> While an open FD 255 is unlikely to be a BPF token, using -1 or ~0U is the
> standard way to provide an invalid FD, which completely eliminates the risk of
> accidentally hitting an open file descriptor.
> 
>> +	);
>> +
>> +	test_map_create_array(&opts, msg);
>> +}
> 

Replied in v13
https://lore.kernel.org/bpf/b22790b4-1e33-4cab-bc2f-92cf7fd60bfd@linux.dev/.

Thanks,
Leon

[...]