Re: [PATCH bpf-next v14 7/8] libbpf: Add syscall common attributes support for map_create

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

On 2026/5/14 09:08, sashiko-bot@kernel.org wrote:
[...]
> 
>> @@ -242,7 +245,18 @@ int bpf_map_create(enum bpf_map_type map_type,
>>  	attr.excl_prog_hash = ptr_to_u64(OPTS_GET(opts, excl_prog_hash, NULL));
>>  	attr.excl_prog_hash_size = OPTS_GET(opts, excl_prog_hash_size, 0);
>>  
>> -	fd = sys_bpf_fd(BPF_MAP_CREATE, &attr, attr_sz);
>> +	log_opts = OPTS_GET(opts, log_opts, NULL);
> 
> Does this code need to validate log_opts with OPTS_VALID(log_opts, bpf_log_opts)?
> 
> Libbpf relies on the OPTS_VALID() macro to enforce ABI forward compatibility
> by verifying that any unrecognized trailing fields in extended option structs
> are explicitly zeroed. While bpf_map_create() correctly validates the outer
> bpf_map_create_opts structure, it seems the nested log_opts structure is
> accessed without similar validation.
> 
> If a newer application populates unsupported fields in struct bpf_log_opts
> with non-zero values, could an older libbpf silently ignore them instead of
> safely rejecting the request with -EINVAL?
> 
Replied in v13
https://lore.kernel.org/bpf/624b092f-e1fe-4a24-9bf6-c505e202b3ef@linux.dev/.

Thanks,
Leon

[...]