Re: [PATCH bpf-next 2/5] bpf: Fix concurrent regression in map_create()

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

On 2026/5/19 23:15, Mykyta Yatsenko wrote:
> 
> 
> On 5/19/26 3:47 AM, Leon Hwang wrote:
>> On 19/5/26 00:43, Mykyta Yatsenko wrote:
>>>
>>>
>>> On 5/18/26 3:54 PM, Leon Hwang wrote:
>>
>>> If map_crate() failed with error code and then log finalization failed, do we really
>>> want to override error code? It sounds like map_create error is more important.
>>>
>>
>> In that case, there are two error codes that should be returned to user
>> space. How to achieve it?
>>
>> Since we should not ignore any error code of them, can we report the
>> error code of __map_create() failure by adding an error attr to struct
>> bpf_common_attr? Hmm, seems not a good idea.
>>
>> Any idea?
> 
> I think we should do what Alexei suggests.
> 
> For example: we return ENOSPC when log is too short, regardless
> of the status of the operation for BPF_PROG_LOAD (see bpf_object_load_prog()
> in libbpf.c), it makes sense to do it consistently for map_create as well.
> 
> log_finalize() error always overrides map_create() error.
> 
> A precedent: We are safe from this race in bpf_prog_load(): bpf_prog_alloc_id() makes
> prog exposed, only after bpf_check() succeeds, which finalizes log.
> We should do similar for map_create().
> 
Thanks for your explanation.

Will send v2 that follows Alexei's suggestion.

Thanks,
Leon