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
