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

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

On 13/5/26 08:33, 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,
> 
> Is it possible for this test to fail spuriously on large systems? If the
> test runs on a machine with 256 or more NUMA nodes where node 255 is
> online, the kernel validation will pass. 
> 
> The map creation might then fail for another reason, skipping the expected
> log message and causing the test to fail.
> 
> Would a value like 0xFFFFFFFE (avoiding NUMA_NO_NODE) be more reliable to
> ensure it exceeds nr_node_ids?
> 

Practically, NUMA nodes number wouldn't be >=255.

Instead of 0xFFFFFFFE, better to get possible numa node number from
/sys/devices/system/node/possible, like libbpf_num_possible_cpus() to
get possible cpu number.

>> +	);
>> +
>> +	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 this also cause an unexpected test failure if file descriptor 255
> happens to be an open BPF token in the test runner? 
> 
> It looks like test_invalid_btf_fd uses -1 to guarantee an invalid file
> descriptor. Does it make sense to use -1 here as well?
> 

Make sense.

Will post a follow-up patch to use -1 here.

Thanks,
Leon

>> +	);
>> +
>> +	test_map_create_array(&opts, msg);
>> +}
>